390 likes | 575 Views
Intelligens rendszerfelügyelet. Szolgáltatási szintek menedzsmentje. Kocsis Imre ikocsis @ mit.bme.hu. Motiváció. Motiváció. Új high score … Shiny …. Azt írják, hogy az outsourcing csodaszer lehet: Központi kompetenciákra fókuszálás Erőforrás-hatékonyság (pénz, humán)
E N D
Intelligens rendszerfelügyelet Szolgáltatási szintek menedzsmentje Kocsis Imre ikocsis@mit.bme.hu
Motiváció Új highscore… Shiny… • Azt írják, hogy az outsourcing csodaszer lehet: • Központi kompetenciákra fókuszálás • Erőforrás-hatékonyság (pénz, humán) • Kockázat-megosztás Total Cost of Ownership… (≠Total Cost of Acquisition) ReturnOnInvestment (finalvalue, initialvalue)
Motiváció Mi facsavart gyártunk. Miért kell nekünk web, levelező- és csoportmunka-szerver? Szervezzük ki! Ha tényleg azt mutatják a számok, hogy ez kell…
Motiváció Én nem tehetek semmit (khm).Főnök, SLA ugye volt a szerződésben? ?!@!!! Nem megy a levelezés! Nem tudok dolgozni! Beperelem a szolgáltatót! ?
Motiváció SLA: Service LevelAgreement. Azt írja, hogy: 99.9% rendelkezésreállás/hónap; 99.9%-99%: 3 nap visszatérítés <99%: 15 nap visszatérítés De amikor évente 50$/user... + Az utóbbi nyolc hónap hat nagy kiesésével is bőven > 99%. Azaz: ennyiért ezt kapjuk.
Motiváció Tanulság: kritikus szolgáltatásokra legyen formális megállapodás az elvárt minőségről, ami egyezik az üzleti célokkal. Mellesleg: ez az IT/IS/… részlegre, mint belső szolgáltatóra is vonatkozik.
Szolgáltatás-kategóriák és minőségi metrikáik
Bevezető • Egy szolgáltatást nyújtó rendszer egymás számára szolgáltatást nyújtó komponensekből épül fel • Funkcionális és {nem|extra}funkcionális jellemzők • Értelmezés: általában szolgáltatáson, rendszeren vagy adaton • Főbb nemfunkcionális jellemző-kategóriák: • Szolgáltatásbiztonság • Teljesítmény • Adatbiztonság
A szolgáltatásbiztonság attribútumai • Rendelkezésre állás (availability) • Helyes szolgáltatás nyújtására készen állás • Megbízhatóság (reliability) • Helyes szolgáltatás folyamatos nyújtása • Biztonságosság (safety) • Katasztrofális következmények hiánya • Integritás (integrity) • „Nem megfelelő” rendszerváltozások hiánya • Karbantarthatóság (maintainability) • Módosíthatóság és javíthatóság Ezek nem metrikák (mérőszámok). 1. Metrika (matematikailag): lásd távolságfüggvények 2. Metrika (IT): - mérhető/számolható… - …rendszer/szolgáltatásjellemző, - rendezett értelmezési tartománnyal - + időintervallum/időpont
Szolgáltatásbiztonsági metrikák • Rendelkezésre állás: annak a valószínűsége, hogy egy rendszer szolgáltatás nyújtására készen áll. • Megbízhatóság: annak a valószínűsége, hogy egy rendszer képes elvégezni a feladatát (egy adott időintervallumban, megadott feltételek mellett). Hibahatás valószínűségi sűrűség függvény
Szolgáltatásbiztonsági metrikák • Ezek valószínűségi változók, mi meg mérni akarunk… • És sokszor csak mintavételezetten tudunk • Availability: „Tapasztalati várható érték” (mintaátlag) • Periodikus mintavételezésből származó hiba! UP DOWN 60 s
Rendelkezésre állás • Tfh. A szolgáltatásunk web hoszting (~50 szerver) • 97%? • ~11 nap kiesés megengedett egy évben • „COTS” hardver elég, „next business day” support sem kell mindenképp • Pipe: nincsenek különösebb igények • 99,9%? • ~9 óra kiesés megengedett egy évben • Erős monitorozás, legalább napi backup • HW hibák ellen: automatizált helyreállítás még működő node-ra beépített redundancia (vagy jó HW) • SLA a hálózati kapcsolatra • 99,999%? (Szégyentelen) önreklám: http://www.saforum.org/about/companies/
Az adatbiztonság attribútumai • Rendelkezésre állás, • Integritás, • Bizalmasság (confidentiality). • Magas szintű, két szolgáltatás (implementáció) összehasonlítását lehetővé tevő metrikák? • A háttérben nincs tiszta, SAP állapotgép • Bináris szemlélet • Megtörték/nem törték meg • Megtörhető/nem megtörhető • Megfigyelhetőség?
Az adatbiztonság metrikái • Az elterjedt (könnyen számolható) metrikák sokszor korlátozottan használhatóak • „Ismert, de nem patch-elt sérülékenységek száma” • „Támadási felület” • „Sérülékenységek historikus alakulása” • … • Elméletben a cél a kockázat szembeállítása lenne a megtérüléssel • Esemény kockázata = valószínűség * költség • Számítása…?
Teljesítmény – szolgáltatás-típusok • Erősen szolgáltatás-típus függő • Van értelme a válaszidőnek IPTV esetén? • Kérés-válasz jellegű szolgáltatások • HTTP, DNS, POP3, adatbázisok, … • (Valósidejű) adatfolyam-szolgáltatások • Streamingaudio/video • Erőforrás-nyújtás szolgáltatások • „utilitycomputing” (Amazon EC2, S3) • Teljesítmény korlátozottan érdekes: • Erőforrás-hozzáférés (resourceallowance) • CPU, tárhely, memória • Esetleg: ütemezés és áteresztőképességek • Diszk I/O
Teljesítmény – szolgáltatás-típusok • Kötegelt feldolgozás • Nyomtatás • Kliensalkalmazások? • Folyamatok teljesítménye • Általánosan is érdekes – lásd pl. backend rendszerek • Kiemelendő: támogató folyamatok (ITIL)
Kérés-válasz szolgáltatások teljesítménye • Feldolgozási idő (processingtime) • Válaszidő (responsetime) • Felhasználó által érzékelt (user-percieved): hálózati késleltetések (latency) + feldolgozási idő • Lehet tovább részletezni • Throughput („átmenő teljesítmény” / „áteresztőképesség”) • # feldolgozott „feladatok”/időegység (s) • Fontos: • Sokaságokat vizsgálunk legalább MIN/MAX/AVG • Küszöbellenőrzésnél ált. megengedünk kisszámú kieső értéket • a kérések 95%-ának válaszideje < 5 s
Kérés-válasz szolgáltatások teljesítménye • Az iparban használt definíciók nem teljesen egységesek • Mi „szabványos”? • Hálózati szint • Amit az egyes tool-ok mérnek • Benchmark-ok egyes metrikái • Teljesítmény-benchmarkok • Cél: tipikus szolgáltatások egyes megvalósításainak egymással összehasonlíthatósága • Szabványos szolgáltatás-definíció • Szabványos terhelés • Szabványos teljesítmény-metrikák • Általában fizetni kell értük
Kérés-válasz szolgáltatások teljesítménye • Standard Performance EvaluationCorporation (SPEC) • SPECjAppServer2004 (J2EE 1.3) • SPECjbb2005 (nagykereskedelmi rendelésfeldolgozás) • SPECweb2005 (HTTP(S); PHP és JSP) • … • TransactionProcessing Performance Council • TPC-App (alkalmazáskiszolgálók, web service-ek) • TPC-C (adatbázisok) • TPC-W (többrétegű, tranzakciókezelő webes szolg.) • Elsődleges metrikák: • „Web Interactions per Second” (WIPS) • „cost per WIPS”
Metrikák kiválasztása és származtatása • Amit eddig elhallgattunk: egy metrikával céljaink szoktak lenni. Pl.: • „Megfelelő” szolgáltatás-minőség definiálása, követése • Magas szintű szolgáltatás-minőségi metrikák származtatása • Rendszerfelügyeleti döntések vezérlése • De: már a szolgáltatási szinten is rengeteg metrika értelmezhető. Mi a fontos? Hogyan válasszunk?
Példa: „Goal – Question - Metric” módszer (GQM) Cél: „online” érzet biztosítása Mennyi ideig kell a felhasználónak várnia, míg megjelenik az oldalunk? Válaszidő Böngésző renderelési idő
Folyamatok minőségjellemzői: néhány ITIL Configuration Management metrika
Folyamatok minőségjellemzői: néhány ITIL Configuration Management metrika
Szolgáltatási szint szerződések • Service LevelAgreement (SLA) • Szolgáltatátó és igénybevevő közötti megállapodás • A szolgáltatás meghatározó minőségi jellemzőiről • A vonatkozó kötelezettségekről mindkét oldalon • Az SLA megsértése esetén való eljárásrendről • Szolgáltató és vevő között általában formális, valódi szerződés • Lehet nem jogi erejű is: belső SLA-k • Ma már gyakorlatilag minden szolgáltatási szektorban • Eredetileg: telco
SLA-k jellemző elemei • A nyújtott szolgáltatás funkcionális leírása • Minőségi jellemzők és korlátaik • Vonatkozó minőségi metrikák definíciója • Célok (SLO-k)/kiértékelés definíciója • Alacsonyabb szintű metrikákból származtatás megadása (lehet rekurzív) • Mérés mikéntjének precíz definíciója
SLA-k jellemző elemei • Szolgáltatási szint monitorozás és jelentés folyamata • Fontos részkérdés: ki mér? • Vevő • Hozzáférés szintje a szolgáltatói infrastruktúrához? • Pontatlanságot okozó zavaró tényezők? • Szolgáltató • Meglevő instrumentáció testre szabása? • Megbízható validálás nélkül?
SLA-k jellemző elemei • Problémák jelentésének a folyamata • Problémákra reagálás és megoldásuk időkeretei • SLA sértés következményei • Felmentő- és kivétel-cikkelyek („escapeclauses”) • Katasztrófák • Nem megfelelő viselkedés a felhasználó részéről • Karbantartási időszakok, munkaidő • Üzleti hatás nélküli kiesések
Leíró nyelvek • A természetes nyelv sokszor elég. • Elektronikus SLA-reprezentáció és megegyezés (negotiation)? • Főleg SOA-forgatókönyvek esetén: • Automatikus (web) service felderítés (discovery) • (Fél)automatikus szolgáltatás-választás • Néhány példa: • Web Service LevelAgreements (WSLA) keretrendszer (IBM) • „Akadémiai” nyelvek: SLAng, WSOL (Web Service OfferingsLanguage), CC-Pi (concurrentconstraint pi calculus), … • WS-Agreement (doménspecifikus nyelv beágyazandó!)
Service Level Management (ITUP) „Service Level Management is the process of negotiating, defining, measuring, managing and improving the quality of IT services at an acceptable cost.”
„Create and Maintain Service Catalog” • ITIL fogalom: szolgáltatás-katalógus • Röviden: egy szervezet által vagy a részlegeinek/alkalmazottainak, vagy a „vevőinek” nyújtott szolgáltatások katalógusa • Összefoghatja pl.: • A szolgáltatás leírását • A vonatkozó SLA-kat • A felhasználókat • A vonatkozó költségeket • A vonatkozó OperationalLevelAgreement-eket • „UnderpinningContracts” • … Magyarul: a szolgáltatás, mint önálló entitás jelenjen meg (és legyen adminisztratívan kezelve)
„Create and MaintainSLA-s” Belső/külső szolgáltatók, OLA-k, UC-k „Finalizing, Committingto, Executingupon, Publishing, …”
„Monitor and Report SLAchievements” Szubjektív elégedettség is!
Referenciák, linkek • D.C. Verma: „Service level agreements on IP networks”. Proceedings of theIEEE, Volume 92, Issue 9, pp 1382 – 1388, 2004. • A. Keller, H.Ludwig: „The WSLA framework: Specifying and monitoring service level agreements for web services”. Journal of Network and Systems Management, Volume 11, Number 1, pp 57-81, Springer, 2003. • M.G. Bruscemi, U. Montanari: „CC-Pi: A Constraint-Based Language for Specifying Service Level Agreements”. In: ProgrammingLanguages and Systems, LNCS 4421, pp 18-32, Springer, 2007. • V. Tosic et al: „Management applications of the web service offerings language (WSOL)”. Information Systems, Volume 30, Number 7, pp 564-586, 2005, Elsevier.
Referenciák, linkek • Web services agreement specification (WS-Agreement). Global Grid Forum, 2004. • http://www.opengridforum.org/Public_Comment_Docs/Documents/Oct-2006/WS-AgreementSpecificationDraftFinal_sp_tn_jpver_v2.pdf • A Avizienis, J.C. Laprie, B. Randell, C. Landwehr, „Basic Concepts and Taxonomy of Dependable and SecureComputing”, IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, 2004, IEEE Computer Society. • Standard Performance Evaluation Corporation • http://www.spec.org • TransactionProcessing Performance Council • http://www.tpc.org • itSMF: Metricsfor IT Service Management. Van Haren Publishing, 2006.