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

Intelligens rendszerfelügyelet

Dr. Pataricza András, Kocsis Imre

Intelligens rendszerfelügyelet

2

Tartalom Cloud Computing

oMit rakjunk a Cloud fölé?oMit rakjunk a Cloud alá?

Ipari és akadémiai kezdeményezéseko IBM Autonomic Computing

Merre tovább?

3

Cloud Computing Átmeneti, nagy számítási feladatok esetén

érdemes lehet igénybe venni Adott egy IaaS szolgáltatás, hogyan oldjunk meg

vele egy feladatot?

→ Szoftverfejlesztés erősen elosztott számítási fürtökreo Hogyan fogjunk hozzá?

4

Számítási fürtök A feladat szétosztása a feldolgozás szervezése, ütemezése

kulcsfontosságúo Saját megoldás fejlesztéseo Valamilyen kész keretrendszer használata

Map-Reduce (Google)o Feladat felírása funkcionális adatfolyam lépésekkelo Keretrendszer ütemezője allokálja a feldolgozási lépéseket

végrehajtóelemekhez Object cache rendszerek

o Pl. Terracotta, o Java szálak transzparens szétosztása külön gépen futó

JVM-ek között

5

Map-Reduce

Output writer

•Nyers bemenetet felbontja szakaszokra•Kulcs-Érték párokat épít belőle•Kulcs-Érték párok halmazát leképezi más kulcs-érték párokra

•A kulcsteret szétbontja partíciókra•Tipikusan hash számítással

•A Map lépések eredményét összegyűjti és sorrendezi a Reduce lépéshez•Aggregálja a kapott kulcs-érték párokat

Input reader

Map

Partition

Compare

Reduce

6

Object Cache rendszerek

JVM1 JVM2

Thread1 Thread2

Objektumokszerializálása,átmásolása

Thread2

Közösen használtobjektumokszinkronban tartása

7

Cloud Computing Mi kerüljön alá? Nyilvánvaló, hogy az erőforrás szolgáltató

cégeknek…o… hatalmas hardverparkra van szüksége

• Komoly költség és energia-hatékonysági megfontolások!o… nagyon jó menedzsment megoldásokat kell

alkalmazniuk• Szisztematikus eljárásrend minden esetre• Automatizálás ahol csak lehet

8

Hardver a „Cloud” alá Hatalmas hardverpark rendel:

o Érdekes új termékfajta: Modular Datacenter pl. Sun S20 (aka. Black Box)

Specifikáció:

- Kívül: szabvány méretű konténer (8-15 t tömeg)- Belül: 8 db szabványos 42 egység magas rack- Áramellátás: 200kW- Hűtés vízzel (25kW/rack kapacitással)- teljes beépített hálózat- földrengésbiztos kivitel mag. 6,5-ig

Forrás: http://www.sun.com/service/sunmd/

9

Hardver a „Cloud” alá

10

Hardver a „Cloud” alá

A Microsoft datacenter víziója:

11

Hardver a „Cloud” alá Google saját szerver építőeleme:

o Gigabyte GA-9IVDP alaplap (saját rendelésre készült, kereskedelmi forgalomban nem kapható)

o Csak egyetlen 12V-os tápellátáso És egy jó nagy akkumulátor… UPS helyett

12

Hardver a „Cloud” alá Google saját szerver építőeleme:

13

Hardver a „Cloud” alá opencompute.org (Facebook)

14

Saját Cloud? Intézmény saját belső cloudot tart fenn

o Van ennek értelme?o Igen, külön részleg foglalkozhat az üzemeltetéssel és

felhasználássalo Főként biztonsági és rendelkezésre állási szempontból

jobb a nyilvános szolgáltatásoknál Saját Cloudot akarok!

o IaaS API szabványtervezet: • OCCI (Open Cloud Computing Interface)

o OpenNebula (http://opennebula.org) mintamegvalósításo Xen, VMware, KVM virtualizációs környezeteket képes

vezérelni

15

Autonóm menedzsment megoldások Trend: inkább olcsó hardverből sokat, mint

drágából keveseto A hibatűrést szoftverből kell megoldanio Ember számára kezelhetetlen méretű rendszer,

automatizálni kell (emberi munkaerő túl drága)

Energiatakarékosság, költségkímélés: o Csak annyi redundancia legyen, amennyi feltétlen kello Okosan kell kihasználni ezt a redundanciáto Takarékoskodni az energiával, amikor csak lehet

16

Tartalom Cloud Computing

oMit rakjunk a Cloud főlé?oMit rakjunk a Cloud alá?

Ipari és akadémiai kezdeményezéseko IBM Autonomic Computing

Merre tovább?

17

A klasszikus nézet

Környezet• Igények• Terhelések• Veszélyek

Infrastruktúra• Erőforrások• Topológia• Adatok• Szolgáltatások

Szolgáltatásbiztonság• Helyesség• Teljesítmény• Ár• Hibatűrés• Adatbiztonság

18

IT mint szolgáltatás

Környezet• Igények• Adatforrások• Terhelések• Veszélyek

??

Infrastruktúra• Erőforrások• Topológia• Adatok• Szolgáltatások

Szolgáltatásbiztonság• Helyesség• Teljesítmény• (Teljesítmény,QoS)/Ár• Hibatűrés• Adatbiztonság

VÁLTOZÓ, ISMERETLEN

ÁLLANDÓ/JAVULÓ

DINAMIKUS, ADAPTÍV

19

A motiváció

Auto

mati

zálá

sO

P T

20

Rendszermenedzsment

Hagyományos

Statikus erőforrás allokáció, rossz hatásfokú kihasználás

Ad hoc folyamatok hibalehetőséget jelentenek, lassúak, munkaigényesek

Nincs összhang az IT folyamatok és az üzleti elvárások között

On-demand, dinamikus

Optimális kapacitás kihasználás, platform mint erőforrás

Visszatérő és komplex folyamatok automatizálása

Proaktív menedzsment magas szintű célok alapján

21

IBM Autonomic Computing IBM Research kezdeményezés 2001-ből

(vision for the future, grand challenge)

Minta: autonóm idegrendszer

„A computing environment with the ability to manage itself and dynamically adapt to change in accordance with business policies and objectives.”

22

Self-* tulajdonságok A számítógép intelligenciájának kihasználása

önfelügyeletre és vezérlésre o Self-* tulajdonságok:

• makroszkópikus• autonóm entitások.

o Lokális mikroszkópikus kölcsönhatások eredménye.

Source: [10]

23

Autonomic Manager

24

Self-* tulajdonságok

• ADAT- ÉS INFORMÁCIÓ- VÉDELEM• Érzékelés,• detektálás,• azonosítás, • reakció

• IT ERŐFORRÁS HATÉKONYSÁG• Terheléselosztás• Erőforrás hangolás

• SZOLGÁLTATÁS HIBATŰRÉS• Hibadetektálás, • - diagnosztika,• - kompenzálás

• REAKCIÓKÉPESSÉG• Adaptáció a dinamikusan

változó környezethez

Önkonfiguráció Öngyógyítás

ÖnvédelemÖnoptimalizálás

29

Rendszermenedzsment mint szabályozás

Szoftver komponens

Szolgáltatás

telepítve

nyújt

Decision Making

Szabályozástechnika

Monitoring

Provisioning

Szabályzott szakasz

Szenzorok

Szabályzó

Beavatkozó

Teljesítmény és szolgáltatásbiztonsági

adatok gyűjtése

Emberi szakértelem vagy automatizálás

Változtatások végrehajtása

alkalmazása IT infrastruktúrán

Szabályozási cél(pl.SLA)

Szabályozási mód

Felügyelt gép Felügyelő/szabályzó gép

30

Mérési konfiguráció Miért nehéz feladat a teljesítménymenedzsment? Teljesítménymodellezés Kísérleti rendszer

31

Architektúra

Relisztikus infrastruktúra: - Több réteg

- Gyakran használt szoftverek

Realisztikus terhelés

Futási időben újrakonfigurálás

Az integrált monitorozás változók széles skáláját figyeli

Integrált intelligens adatfeldolgozás (Matlab)

32

Mért attribútumok Minden attribútumot mérünk, amely releváns

lehet? Csak az adatfeldolgozás során választjuk ki a

tényleg releváns adatokat?

Platform

Ágens

ProcessesÁ

g

e

n

s

Middle-

ware Kliensek

Pl. CPU idle (%), szabad memória (kb),

Pl. MySQL szálak, Tomcat foldolgozási idő,

Apache aktív kapcsolatok

33

A változó kiválasztás problémájaLineáris Entrópia alapú

Cél min E(hiba távolsága2) max (forma hasonlóság)

Tulajdonság megőrzés Egyszerű vetítés Több kontextus

Invariancia Lineáris transzformáció Bármely bijektív függvény

Megőrzött jellemző Átlagos távolság Alak

Sík tükör•Kevés részlet•Kevés torzítás

Szférikus tükör•Több részlet•Nagy torzítás

Paljak, Kocsis, Égel, Tóth, Pataricza: „Sensor Selection for IT infrastructure Monitoring”, AUTONOMICS ‘09

34

Eredmények: példa Hirtelen emelkedő terhelés mellett a szűk

keresztmetszet azonosítása

piros: áteresztőképesség(művelet/s)kék:MySQL-1 Swapfelhasználás (Mbyte)

0 100 200 300 400 500 600 700 800-2

-1.5

-1

-0.5

0

0.5

1

1.5

2

2.5

Lehetséges akciók: taszk migrácó, új kiszolgáló beléptetése a fürtbe

35

Eredmények: példa Hirtelen emelkedő terhelés mellett a szűk

keresztmetszet azonosítása

piros: áteresztőképesség(művelet/s)kék:Adatbázis fürt vezérlő által küldött hálózati csomagokszáma(csomag/s)0 100 200 300 400 500 600 700 800

-3

-2

-1

0

1

2

3

Erős lineáris korreláció azonosítása, késleltetés azonosítása

36

Eredmények: példa Hirtelen emelkedő terhelés mellett a szűk

keresztmetszet azonosítása

piros: áteresztőképesség(művelet/s)kék:Apache szerverteljes CPU kihasználtsága(%)

0 100 200 300 400 500 600 700 800-2

-1.5

-1

-0.5

0

0.5

1

1.5

2

2.5

Szaturáció veszélye: észre kell venni a trendet és proaktív módon beavatkozni

0 100 200 300 400 500 600 700 800-2

-1.5

-1

-0.5

0

0.5

1

1.5

2

2.5

zöld: trend

37

Statikus architektúrák

CentOSApache

Tomcat DB2HW

elemek

A Rendszer

Ha egyszer végre áll csak akkor nyúlunk hozzá, ha tényleg kell

(akkor is megfontoltan)

38

Modellvezérelt…

CMDB

Valóság Mérnöki/üzemeltetőimodell

Felderítés,követés

Modelltranszformáció

Matematikai,analízis modell

Mi idáig főleg ilyenekkel találkoztunk.

A valóságot viszonylag konkrétan ábrázolja.

Valamilyen vizsgálat elvégzéséhez használt

matematikai reprezentáció. Általában absztrakt.

Pl. gráf, hálózati elérhetőségi vizsgálathoz

39

Dinamikus architektúrák Fő ösztönző faktor: erőforráshatékonyság

o Kapacitástervezés: szolgáltatásonként „worst case”?o Hibatűrés: szolgáltatásonként dedikált redundancia?o Energiagazdálkodás?

• Hűtés!

Különböző helyzetekben különböző konfigurációk optimálisak. Példák:o Virtuális gépek erőforrás-allokációjao Gépek megosztása fürtök közötto „utility computing” szolgáltatások bevonásao …

1. Strukturális konfiguráció – de mi az a „struktúra”?2. Parametrikus konfiguráció

40

Dinamikus architektúrák A szükséges technológiák megvannak

o Virtualizáció (számítási kapacitás, tárhely, hálózat)o Nagysebességű hálózatoko „utility computing”oMenet közben átkonfigurálható terhelésmegosztó

fürtöko Ha már itt tartunk: menet közben átkonfigurálható

kiszolgáló-rendszereko… „Apróbb problémák”:

1. Konfiguráció nem megfelelőségének meghatározása2. Optimális célkonfiguráció meghatározása

3. Újrakonfiguráció folyamatának meghatározása

41

Konfiguráció Mgmt

Menedzsment architektúra vázlat

CMDB

IT infrastruktúra

Beépítettszenzorok

Külsőszenzorok

Vizuali-záció

Monitoring

Külsőalkalmazások

Külső DB-k

* Menedzsment

Query interface

42

Topológia felderítés és nyomkövetés Konfigurációs Elemek (CI) és azok

kapcsolatainak felderítése pl.: passzív

megfigyeléso ip1 ip2o Irányított gráfo Kommunikációt

reprezentál

Egyéb infó?

43

Tipikus minták a gráfban Tipikus minták

kigyűjtéseo AutomatikusoManuális

pl.:3 rétegű architektúra

Szolgáltatásfüggőségek!

Web réteg

Kliens réteg

Alkalmazás réteg

Adatbázis réteg

3 tier architecture

44

Rekonfiguráció Aktív reagálás a belső és külső környezeti

változásokraoMeghibásodáso Terhelés változása (QoS vs. energiatakarékosság)o Támadások stb.

Kétféle alapeset:o Parametrikus rekonfigurációo Strukturális rekonfiguráció

45

Parametrikus Rekonfiguráció

Megfigyelés (monitoring)Beavatkozás

Szabályozott rendszer

QoS célérték

Mért QoS érték

Szabályozási döntés

Nehézségek:- Sokféle szabályozható jellemző- Nehezen identifikálható rendszer

Szabályozott rendszermodellje

46

Strukturális Rekonfiguráció A szolgáltatásban résztvevő erőforrások és

szolgáltató elemek kapcsolatainak átrendezéseo virtuális gépek mozgatása hostok közötto feladat-átvételi fürtök

Autonóm megoldási lehetőségeko Statikus rekonfiguráció: előredefiniált konfigurációs

alapesetek (a fürtök tipikusan ilyenek)o Dinamikus rekonfiguráció: találja ki a gép a

konfigurációt • klasszikus mesterséges intelligencia problémák:

optimalizálás, keresések, játékelmélet

47

Strukturális Rekonfiguráció

Megfigyelés, FelderítésBeavatkozás

Futó konfiguráció

QoS célérték

Mért QoS érték

Keresés

Lehetséges rendszerkonfigurációkmodelljei

CMDBNehézségek:

- Sokkal bonyolultabb modell kell- Egy teljesen más konfiguráció teljesítménye nehezen előrejelezhető- Átkonfigurálási tranziensjelenségek modellezése

What-if analízis,hibadiagnosztika

48

Diagnosztika

kiegészítő anyagrész

49

IT rendszerek diagnosztikája A szolgáltatási szintű hibákat (failure) tudni kell…

o Detektálnio Az okokat meghatároznio Javításokat eszközölnio Előre jelezni?

Alkalmas eszközök Megfelelő folyamatok Beépített intelligencia?

50

ITIL folyamatok

Eseményfeldolgozás

IT rendszerek diagnosztikája

Monitorozás

CMDB

Historikus adatgyűjtés

51

ITIL folyamatok

Eseményfeldolgozás

IT rendszerek diagnosztikája

Monitorozás

CMDB

Historikus adatgyűjtés

Mit mérjünk?Határértékek?

…?

Mit gyűjtsünk? Mit kezdjünk vele?

A támogató folyamatoknak is van „konfigurációja”…

52

Rendszerszintű diagnosztika Több évtizedes terület

o Repülő eszközök, katonai eszközök, repülő katonai eszközök…

o Simpson, Sheppard: System Test and Diagnosis Alapfogalom: teszt

o Ütemezetto „active probing”

Diagnosztika stratégiák céljai:o Hibadetektáláso Hibalokalizáláso Hibaizoláláso …optimális javító akció kiválasztása

53

Rendszerszintű diagnosztika Diagnosztika: a javító akciók granularitásáig

o Klasszikusan: komponens csere / újraindításoModern IT: + parametrikus/strukturális rekonfiguráció

Általánosan jellemző: a diagnosztikai probléma formális kezeléseo Diagnosztikai stratégia megfelelőségének vizsgálatao Diagnosztikai/javítási logika szintézise

54

Hardware resourcesSoftware Elements

Service Architecture

Függőségeko erőforráshasználato adatcsere

Hibaterjedés:o erőforrás-állapoto adato… vagy hiánya

Statikus hibaterjedés-analízis

55

generic infrastructure

element

Inputs and outputs: behavior

v0, v0, v3, v2, v0, … reference

v1, v0, v4, v2, v0, … actual

E1, E0, E2, E0, E0, …

Kapcsolatok: protokoll-automata saját abc-vel

Adathiba: egy olyan érték egy adott pillanatban egy kapcsolaton, mely a referencia-rendszerben nem megengedett

Klasszifikáció: „mérnöki tapasztalat”

Statikus hibaterjedés-analízis

56

Error-sorozatok időbeli absztrakciója

PR_UP /OS_OK /NFS_OK

Good_req / [Good_rsp / no_log]Bad_req / [Error_code / req_log]

No_req / [No_rsp / no_log]

PR_DOWN /OS_OK

Good_req / [TCP_denial / no_log]Bad_req / [TCP_denial /no_log]

No_req / [No_rsp / no_log]

OS_DOWN

X / [No_rsp / no_log]

Ami számít: Ha egyáltalán nincs válasz, akkor OS_DOWN(Diagnózis)

Hasonlóan: Ha OS_DOWN, akkor egyáltalán nincs válasz(Hatásanalízis)

57

Ez egy reláció (input, fault_mode, output)!

{„any_input”, „OS_DOWN”, „no_answer”}{„good_requests”, „OK”, „good_answers”}{„any_request”, „PR_DOWN”, „TCP_deny”}…

Hasonlóan: Ha OS_DOWN, akkor egyáltalán nincs válasz(Hatásanalízis)

Error-sorozatok időbeli absztrakciója

Ami számít: Ha egyáltalán nincs válasz, akkor OS_DOWN(Diagnózis)

Bármely bemeneti error-szekvencia

(Véges prefix után) no_rsp error-szekvencia

Belső hibamód állapotsorozat: {OK}*.OS_DOWN

58

E1, E0, E2, E2, E0, …

S5

Rendszerfutás: hibák sorozatai a kapcsolatokon

o „no error” error

Lehetséges hiba-futások halmazának particionálása: szindrómáko Időbeli absztrakcióo Példa: vegyük a legsúlyosabbat ( „súlyossági” reláció!)

Aszinkron és szinkron rendszerekre ugyanaz

Statikus hibaterjedés-analízis

59

Példa: switch, belső hibaok nélkülhiányzó csomag hiányzó csomag

késő csomag késő csomag

rosszul formált csomag hiányzó csomag

adathiba az üzenettörzsben

adathiba az üzenettörzsben

60

Analízis statikus hibaterjedési leírásokkal

Analízis: mik a lehetséges, a leírásokkal és a megfigyelésekkel konzisztens változólekötések?

A diagnózis és a hatásanalízis ugyanaz a probléma!

APPLICATION PROCESS

OS + HW OS + HWNETWORK

WEB SERVER PROCESS

CONNECTION CLIENT

I1F I2 O

f1i1

i2

i2

f2

Finite Domain Constraint Satisfaction

Problem (CSP)

61

Diagnosztika statikus hibaterjedési leírásokkal