Benchmarkok és szolgáltatásbiztonság

Az előadások a következő témára: "Benchmarkok és szolgáltatásbiztonság"— Előadás másolata:

1 Benchmarkok és szolgáltatásbiztonság
Autonóm és hibatűrő informatikai rendszerek Benchmarkok és szolgáltatásbiztonság Utolsó módosítás:

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 Összehasonlítás!
Kapacitástervezési döntéstámogatás Kvalitatív teljesítménytesztelés != valódi teljesítménytesztelés Összehasonlítás! „Akármilyen” metrikát használhatunk 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...
Üzleti folyamatokat Hitelkihelyezési eljárásrendeket Szervezeti hatékonyságot ... A koncepció nem informatika-specifikus

6 Benchmark terminológia
Macrobenchmark nagy összetett alkalmazás/szolgáltatás relevancia biztosításával közvetlenül használható eredményeket ad Microbenchmark alkalmazás kis része/adott kódrészlet Nanobenchmark atomi műveletek teljesítménymérése

7 Benchmarkok Szabványosság, auditálás, verifikálás
Transaction Processing Performance Council (TPC) Standard Performance Evaluation Corporation (SPEC) Business Applications Performance Corporation (BAPCo) ... Nem ipari szervezethez kötött VMMark, openbenchmarking.org, Dhrystone, Whetstone, ...

8 TPC Benchmarkok TPC-C TPC-E TPC-H TPC-Energy
kereskedelmi jellegű adatbázis-tranzakciók + felhasználó-populáció Tranzakció-ráta: tpmC, $/tpmC TPC-E OLTP, „brokerage firm” tps TPC-H Döntéstámogatási rendszerek „TPC-H Composite Query-per-Hour Performance Metric TPC-Energy Additív opcionális benchmark Obsolete: TPC-A, TPC-B, TPC-D, TPC-R, TPC-W, TPC-App

9 Benchmark: szolgáltatás „forráskódot adnak, nekünk kell fordítani”
SPEC Benchmark: szolgáltatás „forráskódot adnak, nekünk kell fordítani” Licenszdíj!

10 SPEC

11 Benchmark terhelési modellek és szempontok
Tudományos/műszaki rendszerek number crunching, párhuzamosság Tranzakciókezelés (OLTP) kliens-szerver környezet, párhuzamos tranzakciók Batch jellegű adatfeldolgozás riport készítés nagy mennyiségű adatból Döntéstámogatás kevés, bonyolult lekérdezés; ad hoc műveletek; „big data” Virtualizáció Kompozit teljesítmény (VM mix); deployment dinamika; interferencia-védelem Cloud? Adatelérés, fel- és leskálázás, durva párhuzamosítás, költséghatékonyság 11

12 Database single-VM measurements
10 users 20 users 50 users

13 Example: database + dbench
This is the effect in the QoS. Relationship with platform metrics? Baseline (10 users) Difference with „disturbance”

14 Benchmark környezet Hogyan specifikáljuk? Alapelvek
Megkötések a mért objektum környezetén (HW/SW) „Szolgáltatás” definíciója Munkaterhelés definíciója Üzemviszonyok Metrikák mérése/számítása Dokumentáció Alapelvek kölcsönös zavarás minimalizálása (üzem közben) terhelés közelítse a valós mintát (profilok)

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 konfigurációs beállítások adott környezet specifikus tulajdonságai Elfogultság Hiányos specifikáció Példák: CPU órajel nem jó teljesítménymérő még a CPU számításokra sem, mert az architektúrák eltérései miatt egy feladattal nagyon eltérő idő alatt végezhetnek azonos órajelű processzorok is Nem releváns metrika egy olyan teszt eredménye, ami főleg a processzorral számoltat, ha a tényleges alkalmazás főleg az I/O-ra vár -”Rátanulunk” a benchmarkra, pl gcc helyett saját fordítót használunk, amit megtehetünk, de kérdés, hogy érdemes-e. -Rejtett paraméter okozhat teljesítménytöbbletet is (pl nagy overheaddel járó funkciók ideiglenes kikapcsolás, pl loggolás)!

16 Benchmark elvégzése Relevancia biztosítása
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. 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ásokra 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 Zavaró tényezőknél figyelembe veendő: a CPU teljesítménye egy adott feladat végrehajtásakor nagyban függ attól, hogy korábban mit hajtott végre. A cache tartalma, TLB bejegyzések a korábban futó taszk számára hasznos adatokat tartalmaznak, az új taszk számára ezek az adatok haszontalanok („hideg a cache”). Minden taszkváltásnál az újonnan futó folyamat eleinte lassan fut, mert kevés a cache találat, eközben „kitújra” az előző folyamat adatait. Ezt hívják cache használatáért versenyzésnek (cache contention). Ezért félrevezető eredményt szolgáltat, ha a benchmark közben más folyamat is fut, még akkor is, ha korrigáljuk az operációs rendszer ütemezője által adott időeredményekkel -> az OS CPU terhelés mérője rossz mérőszám! Hasonló probléma fordulhat elő (bár sokkal nagyobb időléptékben) a diszk cache esetén is. A benchmarkok fajtájától erősen függ, hogy mennyire érzékenyek ilyen jellegű zavarásra.

17 SPECweb2009

18 SPECjvm2008 Ingyenes! JRE teljesítmény Alkalmazások CPU / memória
Kevés állomány I/O, nincs hálózati I/O Alkalmazások 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ág „Hány VM konszolidálható egy hosztra?” 1 „tile”: 6 VM Munkaterhelés Tile-ok számának növelése telítődésig / QoS határig Metrika komponensek normalizált áteresztőképesség-metrikái

20 SPECvirt_sc2010

21 SPECvirt_sc2010

22 Dependability benchmarking
A szolgáltatásbiztonság is benchmarkolható Jellemző megközelítés: Teljesítmény-benchmark + „Hibaterhelés” (fault load) + szolgáltatásbiztonság metrikái Ismétlés: mik ezek? (Lehet implicit!) Vieira, M. (2003). A dependability benchmark for OLTP application environments. of the 29th international conference on Very large data bases (Vol. 94, p. 753). doi:

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

24 Metrikák DBench-OLTP „baseline performance”: tpmC, $/tpmC
TPC-C alapú „baseline performance”: tpmC, $/tpmC Hibaterhelések alatti (átlagos) teljesítmény Tf, $/Tf Értelmezési tartomány: Phase 2 Szolgáltatásbiztonsági metrikák Ne: integritásellenőrzésnél feltárt adathibák AvtS: SUT oldali rendelkezésreállás (válaszidő-korlát!) AvtC: kliensoldali rendelkezésreállás (válaszidő-korlát!)

25 Hibaterhelés

26 Hibaterhelés Itt: operátori hibákkal közelítés Okok:
SW/HW hibák elfogadható emulálása 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észe Horribile dictu implicit módon még folyamatokat is mérünk

27 G. Pintér, H. Madeira, M. Vieira, I. Majzik, A. Pataricza:
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

28 The Autonomic Computing Benchmark
Nagyvállalati környezet „rugalmasságának” vizsgálata (resilience) Self * mérése (önmenedzselés) Hibainjektálással A rendszer robosztusságát és automatizáltságát vizsgálja Cél: kevés metrika Rendszer evolúciójának vizsgálata Különböző rendszerek összehasonlítása Coleman, J., Lau, T., Lokhande, B., Shum, P., Wisniewski, R., & Yost, M. P. (2008). The autonomic computing benchmark. Dependability Benchmarking for Computer Systems (pp. 1-21). IEEE Computer Society. Retrieved from

29 Architektúra Elvben bármi lehet
Példa: SPECjAppServer2004 architektúra / benchmark Webszerver Alkalmazásszerver Adatbázis Üzenetküldő szerver

30 Metrikák Áteresztőképesség index
Zavarok hatása az áteresztőképességre Érettségi index (maturity index): mennyire automatizált a hibadetektálás, hibaanalízis, helyreállás Ábra?

31 Mechanizmus 3 fázis: Tesztfázis: Egymás utáni slot-okban hibainjektálás Ábra?

32 Mechanizmus – 1 slot Állandósult állapotba kerül a rendszer
Hibainjektálás Hibadetektálás Automatikus Bizonyos idő elteltével (emberi interakció szimulálása) Helyreállítás Újraindítás Rendszer futtatása Degradálódott-e a szolgáltatás? Ábra?

33 Hibafajták Hibák (példa): Váratlan leállás (hw, os, sw)
Erőforrás versenyhelyzet (CPU, mem) Adatvesztés (file, DBMS) Terhelésváltozás („karácsonyi roham”) Sikertelen újraindítás detektálása Példák jegyzetben

34 Metrikák (folyt) Áteresztőképesség index: P_i / P_base
Figyelem! Nem rendelkezésre állás. Fejlettség index Kifejezi mennyire automatizált a rendszer Mennyi emberi beavatkozás kell A SUT egy lista alapján pontokat kap Nemlineáris skála Átlagolunk, normalizáljuk Index 0—1 között 0 nincs automatizmus 1 nem kell emberi közbeavatkozás SUT = System Under Test

35 Nehézségek Zavar megtervezése Eredmények összehasonlítása
Zavarok katalógusának összegyűjtése Szimuláció? Eredmények összehasonlítása Terhelés Skálázódás a metrika nem skálázódik feltétlenül együtt a rendszermérettel Ár Robosztus és automatizált rendszer nagyon költséges Benchmark során: emberi interakció becslés!

36 Érettségi szintek