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ő.

Az előadások a következő témára: "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ő."— Előadás másolata:

1 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 ikocsis@mit.bme.hu 2013.11.04.

2 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 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 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 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 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 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 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 (QphH@Size)”  TPC-Energy o Additív opcionális benchmark  Obsolete: TPC-A, TPC-B, TPC-D, TPC-R, TPC-W, TPC-App

9 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 10 SPEC

11 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 12 Database single-VM measurements 10 users 20 users 50 users

13 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 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 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 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 17 SPECweb2009

18 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 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 20 SPECvirt_sc2010

21 21 SPECvirt_sc2010

22 22 IaaS performance HW not necessarily known Unknown / uncontrollable deployment Unknown / uncontrollable scheduling Unknown / uncontrollable scheduling „Noisy neighbors” Also: management action performance?

23 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 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 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 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 27 Mérési kampány struktúrája

28 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 29 Hibaterhelés

30 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 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 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 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 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 35 Mechanizmus  3 fázis:  Tesztfázis: Egymás utáni slot-okban hibainjektálás

36 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 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 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 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 40 Érettségi szintek