Intelligens rendszerfelgyelet Dr Pataricza Andrs Kocsis Imre Budapesti

Intelligens rendszerfelügyelet Dr. Pataricza András, Kocsis Imre Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék 1

Tartalom § Cloud Computing o Mit rakjunk a Cloud fölé? o Mit rakjunk a Cloud alá? § Ipari és akadémiai kezdeményezések o IBM Autonomic Computing § Merre tovább? 2

Cloud Computing § Átmeneti, nagy számítási feladatok esetén érdemes lehet igénybe venni § Adott egy Iaa. S szolgáltatás, hogyan oldjunk meg vele egy feladatot? § → Szoftverfejlesztés erősen elosztott számítási fürtökre o Hogyan fogjunk hozzá? 3

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ése o Valamilyen kész keretrendszer használata § Map-Reduce (Google) o Feladat felírása funkcionális adatfolyam lépésekkel o 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 4

Map-Reduce • Nyers bemenetet felbontja szakaszokra • Kulcs-Érték párokat épít • Kulcs-Érték párok halmazát belőle leképezi más kulcs-érték párokra Input reader Map Partition • A kulcsteret szétbontja partíciókra • Tipikusan hash számítással Compare • A Map lépések eredményét összegyűjti és sorrendezi a Reduce lépéshez Reduce • Aggregálja a kapott kulcsérték párokat Output writer 5

Object Cache rendszerek Objektumok szerializálása, átmásolása Thread 1 Thread 2 Közösen használt objektumok szinkronban tartása JVM 1 Thread 2 JVM 2 6

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 7

Hardver a „Cloud” alá § Hatalmas hardverpark rendel: o Érdekes új termékfajta: Modular Datacenter pl. Sun S 20 (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: 200 k. W - Hűtés vízzel (25 k. W/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/ 8

Hardver a „Cloud” alá 9

Hardver a „Cloud” alá A Microsoft datacenter víziója: 10

Hardver a „Cloud” alá § Google saját szerver építőeleme: o Gigabyte GA-9 IVDP alaplap (saját rendelésre készült, kereskedelmi forgalomban nem kapható) o Csak egyetlen 12 V-os tápellátás o És egy jó nagy akkumulátor… UPS helyett 11

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

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

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ással o 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 Iaa. S API szabványtervezet: • OCCI (Open Cloud Computing Interface) o Open. Nebula (http: //opennebula. org) mintamegvalósítás o Xen, VMware, KVM virtualizációs környezeteket képes vezérelni 14

Autonóm menedzsment megoldások § Trend: inkább olcsó hardverből sokat, mint drágából keveset o A hibatűrést szoftverből kell megoldani o 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 kell o Okosan kell kihasználni ezt a redundanciát o Takarékoskodni az energiával, amikor csak lehet 15

Tartalom § Cloud Computing o Mit rakjunk a Cloud főlé? o Mit rakjunk a Cloud alá? § Ipari és akadémiai kezdeményezések o IBM Autonomic Computing § Merre tovább? 16

A klasszikus nézet Környezet • Igények • Terhelések • Veszélyek Infrastruktúra Szolgáltatásbiztonság • Helyesség • Teljesítmény • Ár • Hibatűrés • Adatbiztonság • Erőforrások • Topológia • Adatok • Szolgáltatások 17

IT mint szolgáltatás VÁLTOZÓ, ISMERETLEN Környezet • • ÁLLANDÓ/JAVULÓ Igények Adatforrások Terhelések Veszélyek Szolgáltatásbiztonság • Helyesség • Teljesítmény • (Teljesítmény, Qo. S)/Á r • Hibatűrés • Adatbiztonság ? ? DINAMIKUS, ADAPTÍV Infrastruktúra • • Erőforrások Topológia Adatok Szolgáltatások 18

Automatizálás OPT A motiváció 19

Rendszermenedzsment § Hagyományos § On-demand, dinamikus § Statikus erőforrás allokáció, rossz hatásfokú kihasználás § Optimális kapacitás kihasználás, platform mint erőforrás § Ad hoc folyamatok hibalehetőséget jelentenek, lassúak, munkaigényesek § Visszatérő és komplex folyamatok automatizálása § Nincs összhang az IT folyamatok és az üzleti elvárások között § Proaktív menedzsment magas szintű célok alapján 20

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. ” 21

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] 22

Autonomic Manager 23

Self-* tulajdonságok • REAKCIÓKÉPESSÉG • Adaptáció a dinamikusan változó környezethez • SZOLGÁLTATÁS HIBATŰRÉS • Hibadetektálás, • - diagnosztika, • - kompenzálás Önkonfiguráció Öngyógyítás Önoptimalizálás Önvédelem • IT ERŐFORRÁS HATÉKONYSÁG • Terheléselosztás • Erőforrás hangolás • ADAT- ÉS INFORMÁCIÓVÉDELEM • Érzékelés, • detektálás, • azonosítás, • reakció 24

Rendszermenedzsment mint szabályozás Szabályozástechnika alkalmazása IT infrastruktúrán Szolgáltatás Teljesítmény és szolgáltatásbiztonsági adatok gyűjtése Szenzorok Monitoring Szabályozási cél (pl. SLA) nyújt Decision Szabályzó Making Szabályzott Szoftver szakasz komponens telepítve Szabályozási mód Beavatkozó Provisioning Emberi szakértelem vagy automatizálás Változtatások végrehajtása Felügyelt gép Felügyelő/szabályzó gép 29

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

Integrált intelligens adatfeldolgozás (Matlab) Architektúra Realisztikus terhelés Futási időben újrakonfigurálás Relisztikus infrastruktúra: -Több réteg - Gyakran használt szoftverek Az integrált monitorozás változók széles skáláját figyeli 31

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? Pl. My. SQL szálak, Tomcat foldolgozási idő, Apache aktív kapcsolatok Processes Pl. CPU idle (%), szabad memória (kb), Ágens Middleware Platform 32 Á g e n s Kliensek

A változó kiválasztás problémája Lineáris Entrópia alapú Cél min E(hiba távolsága 2) 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”, 33 AUTONOMICS ‘ 09

Eredmények: példa § Hirtelen emelkedő terhelés a szűk Lehetséges akciók: taszk mellett migrácó, új kiszolgálóazonosítása beléptetése a fürtbe keresztmetszet piros: áteresztőképesség (művelet/s) kék: My. SQL-1 Swap felhasználás (Mbyte) 34

Eredmények: példa §Erős Hirtelen emelkedő mellett a szűk lineáris korrelációterhelés azonosítása, késleltetés keresztmetszetazonosí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 csomagok száma (csomag/s) 35

Eredmények: példa § Hirtelenveszélye: emelkedő terhelés mellett a szűkés Szaturáció észre kell venni a trendet proaktív módon beavatkozni keresztmetszet azonosítása piros: áteresztőképesség (művelet/s) kék: Apache szerver teljes CPU kihasználtsága (%) zöld: trend 36

Statikus architektúrák A Rendszer Cent. OS Apache Tomcat DB 2 HW elemek Ha egyszer végre áll csak akkor nyúlunk hozzá, ha tényleg kell (akkor is megfontoltan) 37

Modellvezérelt… Modell transzformáció Felderítés, követés CMDB Valóság Mérnöki/üzemeltetői modell Mi idáig főleg ilyenekkel találkoztunk. A valóságot viszonylag konkrétan ábrázolja. Matematikai, analízis modell 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 38

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ója o Gépek megosztása fürtök között o „utility computing” szolgáltatások bevonása o… 1. Strukturális konfiguráció – de mi az a „struktúra”? 2. Parametrikus konfiguráció 39

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ózatok o „utility computing” o Menet közben átkonfigurálható terhelésmegosztó fürtök o Ha már itt tartunk: menet közben átkonfigurálható kiszolgáló-rendszerek o… „Apróbb problémák”: 1. Konfiguráció nem megfelelőségének meghatározása 2. Optimális célkonfiguráció meghatározása 3. Újrakonfiguráció folyamatának meghatározása 40

Menedzsment architektúra vázlat * Menedzsment Vizualizáció Konfiguráció Mgmt Külső alkalmazások CMDB Monitoring Query interface Beépített szenzorok Külső DBk Külső szenzorok 41 IT infrastruktúra

Topológia felderítés és nyomkövetés § Konfigurációs Elemek (CI) és azok kapcsolatainak felderítése § pl. : passzív megfigyelés o ip 1 ip 2 o Irányított gráf o Kommunikációt reprezentál § Egyéb infó? 42

Tipikus minták a gráfban Kliens réteg § Tipikus minták kigyűjtése o Automatikus o Manuális Web réteg § pl. : 3 rétegű architektúra § Szolgáltatás függőségek! Alkalmazás réteg Adatbázis réteg 3 tier architecture 43

Rekonfiguráció § Aktív reagálás a belső és külső környezeti változásokra o Meghibásodás o Terhelés változása (Qo. S vs. energiatakarékosság) o Támadások stb. § Kétféle alapeset: o Parametrikus rekonfiguráció o Strukturális rekonfiguráció 44

Parametrikus Rekonfiguráció Megfigyelés (monitoring) Beavatkozás Szabályozott rendszer Mért Qo. S érték Qo. S célérték Nehézségek: - Sokféle szabályozható jellemző - Nehezen identifikálható rendszer Szabályozási döntés Szabályozott rendszer modellje 45

Strukturális Rekonfiguráció § A szolgáltatásban résztvevő erőforrások és szolgáltató elemek kapcsolatainak átrendezése o virtuális gépek mozgatása hostok között o feladat-átvételi fürtök § Autonóm megoldási lehetőségek o 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 46

Strukturális Rekonfiguráció Megfigyelés, Felderítés Beavatkozás Nehé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 Mért Qo. S érték Futó konfiguráció CMDB Keresés Lehetséges rendszer konfigurációk modelljei 47 What-if analízis, hibadiagnosztika Qo. S célérték

Diagnosztika kiegészítő anyagrész 48

IT rendszerek diagnosztikája § A szolgáltatási szintű hibákat (failure) tudni kell… o Detektálni o Az okokat meghatározni o Javításokat eszközölni o Előre jelezni? § Alkalmas eszközök § Megfelelő folyamatok § Beépített intelligencia? 49

IT rendszerek diagnosztikája ITIL folyamatok Eseményfeldolgozás Monitorozás CMDB Historikus adatgyűjtés 50

IT rendszerek diagnosztikája A támogató folyamatoknak is van „konfigurációja”… …? ITIL folyamatok Eseményfeldolgozás Monitorozás Mit mérjünk? Határértékek? CMDB Historikus adatgyűjtés Mit gyűjtsünk? Mit kezdjünk vele? 51

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 Ütemezett o „active probing” § Diagnosztika stratégiák céljai: o Hibadetektálás o Hibalokalizálás o Hibaizolálás o …optimális javító akció kiválasztása 52

Rendszerszintű diagnosztika § Diagnosztika: a javító akciók granularitásáig o Klasszikusan: komponens csere / újraindítás o Modern IT: + parametrikus/strukturális rekonfiguráció § Általánosan jellemző: a diagnosztikai probléma formális kezelése o Diagnosztikai stratégia megfelelőségének vizsgálata o Diagnosztikai/javítási logika szintézise 53

Statikus hibaterjedés-analízis § Függőségek o erőforráshasználat o adatcsere § Hibaterjedés: o erőforrás-állapot o adat o … vagy hiánya 54

Statikus hibaterjedés-analízis § Kapcsolatok: protokollautomata saját abc-vel § Adathiba: egy olyan érték egy adott pillanatban egy kapcsolaton, mely a referencia-rendszerben nem megengedett Inputs and outputs: behavior v 0, v 3, v 2, v 0, … v 1, v 0, v 4, v 2, v 0, … § Klasszifikáció: „mérnöki tapasztalat” 55 E 1, E 0, E 2, E 0, … reference actual

Error-sorozatok időbeli absztrakciója 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) 56

Error-sorozatok időbeli absztrakciója 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) Bármely bemeneti. Belső hibamód (Véges prefix után) no_rsp errorállapotsorozat: error-szekvencia {OK}*. OS_DOWN szekvencia 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”} … 57

Statikus hibaterjedés-analízis § Rendszerfutás: hibák sorozatai a kapcsolatokon E 1, E 0, E 2, E 0, … o „no error” error S 5 § Lehetséges hiba-futások halmazának particionálása: szindrómák o Időbeli absztrakció o Példa: vegyük a legsúlyosabbat ( „súlyossági” reláció!) § Aszinkron és szinkron rendszerekre ugyanaz 58

Példa: switch, belső hibaok nélkül hiányzó csomag késő csomag rosszul formált csomag hiányzó csomag adathiba az üzenettörzsben 59

Analízis statikus hibaterjedési leírásokkal Finite Domain Constraint Satisfaction Problem (CSP) § 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! 60

Diagnosztika statikus hibaterjedési leírásokkal 61