Sziasztok!
Holnap úgy néz ki elég sokan szabin leszünk (én és Biczók Gergpő
biztosan), ezért ha lehet a meetingünket kihagyhatnánk holnap.
Elnézést a short notice-ért!
Azért haladtunk a munkával a legutóbbi meeting óta, Dóri összefoglalóját
a munkáról küldöm alább:
A megbeszélésen odáig jutottunk, hogy ha a rendszerben előforduló
szolgáltatások mindegyike csak egy másik szolgáltatástól függ, akkor
hogyan számítható a hibaterjedés a rendszeren. Azóta azon dolgozunk,
hogy ezt a hibaterjedési modell kiterjesszük arra az esetre, amikor
egy-egy szolgáltatásnak több dependenciája is van és a dependenciák
hibaállapotait aggregálnunk kell. Több lehetséges stratégiát is
megvizsgáltunk. A naiv megoldás az lenne, ha a dependenciák minden
lehetséges hibaállapot-kombinációját szimulálva kimérjük az eredő
hibaállapotot. Ez nagyon pontos hibamodellt adna, viszont a sok mérés
miatt elég rosszul skálázódik.
Ehelyett inkább arra gondoltunk, hogy a dependenciák hibaállapotait,
mint halmazt nézzük és ebből a halmazból választanánk a legrosszabb
hibaállapotot, mint a továbbterjedő hibaállapot, vagyis worst-case-t
számolnánk. Sajnos a hibaállapotok halmaza nem teljesen rendezhető, mert
előfordulnak hibaállapotok, amelyek összehasonlításkor egyik dimenzióban
jobbak, másikban rosszabbak. Pl. a "korrekt, de későn érkező válasz"
hibáját kell összehasonlítanunk a "időben érkező, de hibás válasz"
hibájával. Ezek között nem lehet általánosan, minden rendszerre igaz
módon megmondani, hogy melyik rosszabb, mert ez az adott rendszer
követelményeitől függ.
Ezért azt javasoljuk, hogy az impact analízist egy-egy system
capability-re (integrity, availability, ...) koncentrálva végezzük el.
Az integrity fókuszú elemzéskor csak a helyes-helytelen válasz
dimenzióban mozogva teljesen rendezhető a hibaállapotok halmaza: a
helytelen válasz mindig rosszabb, mint a helyes. Availability-re
fókuszálva is teljesen rendezhető a hibaállapotok halmaza: a normál
időzítéssel érkező válasznál rosszabb a késve érkező válasz (delay:
increased), aminél még rosszabb, ha néha időtúllépés miatt nem érkezik
válasz (responsiveness: sometimes), de a legrosszabb, ha sose érkezik
válasz időkorláton belül (responsiveness: never).
Ennek a megközelítésnek nagy előnye, hogy csak páronként kell a
hibaállapotok mérését elvégezni, az összesítést és elemzést plusz
mérések nélkül el lehet végezni, vagyis remélhetőleg jól skálázódik. A
hátránya viszont, hogy nem vesz figyelembe olyan eseteket, amikor a
hibadimenziók hatnak egymásra, pl. helytelen válaszokat küldő
dependencia miatt egy-egy szolgáltatás lelassul vagy kiesik. Még
gondolkozunk, hogyan lehetne ezeket az eseteket skálázhatóak kezelni.
Köszönettel:
Levente
--
Prof. Levente Buttyán
Laboratory of Cryptography and System Security (CrySyS Lab)
Department of Networked Systems and Services
Budapest University of Technology and Economics (BME)
https://www.crysys.hu/
