1 Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Benchmarkok és szolgáltatásbiztonság Autonóm és hibatűrő információs rendszerek Kocsis Imre

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álhatunk o 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 folyamatokat o Hitelkihelyezési eljárásrendeket o Szervezeti hatékonyságot o...  A koncepció nem informatika-specifikus

6 Benchmark terminológia  Macrobenchmark o nagy összetett alkalmazás/szolgáltatás o relevancia biztosításával közvetlenül használható eredményeket ad  Microbenchmark o alkalmazás kis része/adott kódrészlet  Nanobenchmark o 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ött o 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-E o OLTP, „brokerage firm” o tps  TPC-H o Döntéstámogatási rendszerek o „TPC-H Composite Query-per-Hour Performance Metric  TPC-Energy o Additív opcionális benchmark  Obsolete: TPC-A, TPC-B, TPC-D, TPC-R, TPC-W, TPC-App

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

10 SPEC

11  Tudományos/műszaki rendszerek o number crunching, párhuzamosság  Tranzakciókezelés (OLTP) o kliens-szerver környezet, párhuzamos tranzakciók  Batch jellegű adatfeldolgozás o riport készítés nagy mennyiségű adatból  Döntéstámogatás o 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 measurements 10 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? 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ója o Munkaterhelés definíciója o Üzemviszonyok o Metrikák mérése/számítása o Dokumentáció  Alapelvek o kölcsönös zavarás minimalizálása (üzem közben) o terhelés közelítse a valós mintát (profilok) Benchmark 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ások o 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ásokra o 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ória o Kevés állomány I/O, nincs hálózati I/O  Alkalmazások o 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 o „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 IaaS performance HW not necessarily known Unknown / uncontrollable deployment Unknown / uncontrollable scheduling Unknown / uncontrollable scheduling „Noisy neighbors” Also: management action performance?

23 IaaS performance  Deployment decisions o Should I use this cloud?  Capacity planning o Type and amount of res.  Perf. prediction o QoS to be expected o And its deviances Benchmarking!

24 Benchmarking (a pragmatic take on)  (De-facto) standard applications  with well defined execution metrics  that may exercise specific subsystems  to compare IT systems via said metrics.  Popular benchmarks: e.g. Phoronix Test SuitePhoronix Test Suite  Benchmarking as a Service: cloudharmony.comcloudharmony.com

25 Campaign types All benchmarks & test cases Single resource type instances Reduced set of benchmarks &test cases Resource types: multiple instances (5-6) Further reduced set Single resource type instances Continous or sampling operation Baseline „Spatial variance”/„unlucky roll” Temporal variance

26 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!)

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

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

29 Hibaterhelés

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

31 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 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

32 The Autonomic Computing Benchmark  Nagyvállalati környezet „rugalmasságának” vizsgálata (resilience) o Self * mérése (önmenedzselés) o Hibainjektálással o A rendszer robosztusságát és automatizáltságát vizsgálja  Cél: kevés metrika o Rendszer evolúciójának vizsgálata o Különböző rendszerek összehasonlítása

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

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

35 Mechanizmus  3 fázis:  Tesztfázis: Egymás utáni slot-okban hibainjektálás

36 Mechanizmus – 1 slot  Állandósult állapotba kerül a rendszer  Hibainjektálás  Hibadetektálás o Automatikus o 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?

37 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

38 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 rendszer o Mennyi emberi beavatkozás kell o A SUT egy lista alapján pontokat kap o Nemlineáris skála o Átlagolunk, normalizáljuk o Index 0—1 között 0 nincs automatizmus 1 nem kell emberi közbeavatkozás

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

40 Érettségi szintek