Autonóm számítástechnika ( Autonomic computing )

1. Autonóm számítástechnika(Autonomiccomputing) Fogalmak és esettanulmányok

2. Bevezetés • Az AC egy rendszerszintű megközelítés • Automatizálás és felügyelhetőség a rendszer minden rétegében • Federált, heterogén komponenensekkohezívan együttműködnek • Három alapvető elv szerint fejlődnek AC rendszerek • szabályozástechnika • dinamikus tervkésztés • reflektív, self-aware rendszerek Azautonomic computing (AC, autonóm informatika)az autonóm idegrendszert modellező rendszertervezési paradigma. A rendszer alapvető állapotváltozóiban bekövetkező változás a teljes rendszert viselkedését megváltoztató beavatkozást vált ki, amely biztosítja, hogy a rendszer egyensúlyi állapotba kerül a környezetével.

3. Motivation for Autonomic Computing Research directions • System Uncertainty • Very large scales • Ad hoc structures/behaviours • p2p, hierarchical, … • Dynamic • entities join, leave, change behaviour • Heterogeneous • capability, connectivity, reliability, • Lack of guarantees • components, communication • Lack of common/complete knowledge • number, type, location, availability, connectivity, protocols, semantics • Information Uncertainty • Availability, resolution, quality of information • Devices capability, operation, calibration • Trust in data, data models • Semantics • Application Uncertainty • Dynamic behaviours • space-time adaptivity • Dynamic and complex couplings • multi-physics, multi-model, multi-resolution, …. • Dynamic and complex (ad hoc, opportunistic) interactions • Software/systems engineering issues • Emergent rather than by design

4. Self-* tulajdonságok • A self-* (ön*) tulajdonságok AC rendszerek makroszkopikus tulajdonságai

5. Önkonfiguráció - Self-configuration • Automatikus adaptáció a dinamikusan változó környezethez • Belső adaptáció • Komponensek hozzáadása vagy elvétele (software) • Futás közbeni újrakonfiguráció • Külső adaptáció • A globális infrastruktúra szerintsaját magát állítja be a rendszer Belső állapot Környezet

6. Öngyógyítás - Self-healing • Külső zavarás felismerése, diagnosztizálása és szolgáltásmegszakítás nélküli kezelése • Autonóm problémafelismerés és megoldás • A hibás komponenseket • detektálni, • izolálni, • javítani, • újraintegrálni. Hibás komponens

7. Önoptimalizáció - Self-optimization • Erőforrásokautomatikus monitorozása, hangolása, felügyelete • Működés nem előre jelezhető körülmények között • Erőforrás kihasználás maximalizálásaemberi beavatkozás nélkül • Dinamikus erőforrás allokáció ésterhelés menedzsment • Erőforrás: tárhely, adatbázis, hálózat • Példa: dinamikus szerver fürtök Resourcemanagement

8. Önvédelem - Self-protection • Támadásokra való felkészülés, detektálás, azonosítás és védelem • Felhasználói hozzáférés definiálása és felügyeleteminden erőforrásra • Jogosulatlan hozzáférés ellenivédelem Belső erőforrás Külső erőforrás

9. Általánosított „ágens”

10. Autonomic Element - AE Autonomic Manager Analyze Plan Monitor Execute Knowledge Managed Element S E • Az architektúra alapeleme a • Felügyelt egységből • Adatbázis, alkalmazásszerver , stb • És autonóm menedzserből álló • Autonóm egység • Feladatai: • A funkcionalitás nyújtása • Saját viselkedésének felügyelete a self-* tulajdonságok alapján • Együttműködés más autonóm egységekkel Az autonóm egység

11. AE: Kölcsönhatások • Kapcsolatok AE-k között: • Dinamikus, ideiglenes, célorientált • Szabályok és kényszerek definiálják • Egyezség által jön létre • Ez lehet tárgyalás eredménye • Teljes spektrum • Peer-to-peer • Hierarchikus • Házirendek (policy) szabályozhatják

12. Önszervezés • Az önszervezés • alacsony szintű egységekben végrehajtott • dinamikus folyamatok összessége, amely során • struktúra vagy rend jelenik meg • globális szinten. • Az önszervező viselkedést eredményező szabályokat (amelyek a kölcsönhatásokat meghatározzák) az AE-k csupán lokális információ alapján alkalmazzák

13. AC referencia architektúra Részben vagy teljesen automatizált folyamatok(pl. ITIL folyamatok) Építőelemek kombinálása tipikusforgatókönyvekké IT építőelemek, és összekapcsolásukleírása Az AC rendszer által felügyelt erőforrások

14. Autonóm Kölcsönhatás

15. Hogyan lesz a nyers adatból metrika?

16. Kitekintés: AC vs AI • Policy (~szabály, házirend, eljárásrend) alapú tervezés • Állapot alapú • Action • Explicit ha-akkor (~üzleti szabály) • Goal • Mi a „megcélzott” állapot? • A rendszer dönti el a konkrét akciót (pl. heurisztika) • Utilityfunction (hasznosság) • Minden állapotnak „értéke” van • Nem bináris a hasznosság (nem egyértelmű a célállapot) • Rugalmasabb működés, nehezebb specifikáció

17. Példa: Action policy • „Gold” és „Silver” tranzakciók egy adatközpontban • Policy ütközés, „vergődés” Mi lesz az osztott erőforrásokkal? Megoldás: a priori tudás bevitele (pl. Gold fontosabb, mint Silver, bizonyos szint fölött nem kérünk plusz CPU-t, másik szerverre allokáljuk a terhelést, … )

18. Példa: Goal policy • Ugyanaz az adatközpont, cél: • „Vágyott/célzott tartományok” Adott terhelés és erőforráskészlet mellett T: adott tranzakcióosztály válaszideje C: erőforrás α: kapcsolat a CPU és a válaszidő közt λ: terhelés (egyszerű sorbanállási modell alapján)

19. Példa: hasznosság alapú policy • Pl. SLA alapján • Vezérelhet cél alapú policyt, pl. erőforrás menedzser szintjén • Egyszerű specifikáció, komplex döntési logika

20. Kihívások, feltételezések • A hasznosság előre ismert • Rossz specifikáció: Silver osztály „éhezik” • Nincsenek kiugróan fontos/hosszú tranzakciók • Taszkváltás hatása elhanyagolható • Válaszidő egyértelműen mérhető • Átlag? Max? • Az erőforrásmenedzsment hatékony • Nem ront a helyzeten az átkonfigurálás

21. Autonóm rendszerek összehasonlítása • QoS • Költség • Rugalmasság/Granularitás • Autonómia foka • Adaptivitás • Reakcióidő • Érzékenység • Stabilitás

22. Esettanulmány: CoMiFin Szolgáltatásalapú rendszerek, modellvezérelt fejlesztés, komplex eseményfeldolgozás,…

23. Esettanulmány: CoMiFin • „CommunicationMiddlewarefor Financial Infrastructures” • Motiváció • Banki rendszerek egyre erősebben függenek külső szolgáltatóktól • Támadások egyre kifinomultabbak • Kritikus infrastruktúrák (pl. mobilhálózat, áramellátás, Internet) elleni komplex támadások kivédése • Hagyományos kommunikáció lassú (példa: 8 nap egy eset lezárása) • Cél • Schemetosetup and manage a secureenvironment (software, hardware, monitoring tools, etc.) forinformationexchange and analysis • Tanszéki spin-off (OptXware) vezette a demonstrátor fejlesztését

24. Példa: magyar infrastruktúra

25. Logikai architektúra

26. Online adatfeldolgozás (CEP)

27. Architektúra Financial Institutions (FI)emulated by Gateways Logical management (SR creation, …) Monitoring and evaluationSLA management, visualization Reliable communication (currently: Java Message Service) ED Event Processing (DHT) (ED Testbed, Rome) CoMiFin management components (OptXwaretestbed, Budapest) IBM Event Processing (AGILIS) (IBM Testbed, Haifa)

28. „Szabályozási kör” (részben készült el)

29. Példa monitorozás megvalósítására

30. Eredmények megjelenítése

31. Források • Kephart, J. O., & Chess, D. M. (2003). The vision of autonomiccomputing. Computer, 36(1), 41-50. IEEE Computer Society. doi:10.1109/MC.2003.1160055 • McCann, J., & Huebscher, M. C. (2004). Evaluationissuesinautonomiccomputing. Grid and CooperativeComputing – GCC 2004 Workshops (pp. 597–608). Springer. doi:10.1007/978-3-540-30207-0_74 • Kephart, J. O., & Walsh, W. E. (2004). An artificialintelligenceperspectiveonautonomiccomputingpolicies. Proceedings. Fifth IEEE International WorkshoponPoliciesforDistributed Systems and Networks, 2004. POLICY 2004. (pp. 3-12). IEEE. doi:10.1109/POLICY.2004.1309145 • LászlóGönczy, GyörgyCsertán, GáborUrbanics, HamzaGhani, AbdelmajidKhelil and NeerajSuri. Monitoring and Evaluation of Semantic Rooms. InCollaborative Financial InfrastructureProtection, Springer, 2012. http://www.springerlink.com/content/l0v4n4185617uq35/ • http://comifin.eu/