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/
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
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
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]
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
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)
Top Related