Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Laser 4-dynamic update

252 views

Published on

Fourth lecture at the LASER Summer School, Elba Island, Sept. 2013

Published in: Technology, Real Estate
  • Be the first to comment

Laser 4-dynamic update

  1. 1. Development of dynamically evolving and self-adaptive software 4. Dynamic software update LASER 2013 Isola d’Elba, September 2013 Carlo Ghezzi Politecnico di Milano Deep-SE Group @ DEIB 1 Sunday, September 15, 13
  2. 2. The problem • Once you detect that a change has to be made to your running configuration, how do you react? A solution • Replace distributed configuration A with B Assumption • Componentized distributed implementation • Implementation structured as a program family • Reconfiguration = new family member instantiated 2 Sunday, September 15, 13
  3. 3. The problem • Traditional approach to software updates - Shut-down the system - Perform update - Restart • Traditional program families instantiated statically • Here we need a dynamic program family 3 Sunday, September 15, 13
  4. 4. Requirement • The dynamic update has to be: • Efficient • Low disruption minimize the interruption of the system’s service • Timely minimize the delay with which the system is updated • Safe • It must not lead the system into unexpected erroneous behavior. 4 Sunday, September 15, 13
  5. 5. Our setting • We assume we know the architecture of the system - System components and their interaction • Based on the architecture, we define how can we safely replace a component at run-time by - providing a condition to safely and efficiently substitute components at run-time - an algorithm to ensure this condition - a framework that practically enables safe runtime replacement of components when this condition is satisfied 5 Sunday, September 15, 13
  6. 6. Software architecture model • Component-based distributed systems may be described by the static configuration: • A directed graph whose: • nodes represent components with in-ports and out-ports • directed edges represents static dependences Auth com :/Component :/Static,Dependence Portal DB Proc Static,configuration,/ of/an/example/CBDS/7 6 Sunday, September 15, 13
  7. 7. Transactions • A transaction is a sequence of actions executed by a component that completes in bounded time • Actions include: • Local computations • Message exchanges • A transaction can be: • a root transaction if initiated by an outside client • a sub-transaction if initiated by another transaction • A distributed transaction includes the root transaction and all (direct and indirect) sub-transactions 7 Sunday, September 15, 13
  8. 8. Transactions Portal Portal Auth Auth Proc Proc DBAccess DBAccess getToken (cred) root$transaction$ $ return token T1 T1 process (token,data) verify(token) T0 T0 T3 T3 ok T2 T2 sub,transaction$ $ dbOperation() T4 T4 db result proc result 8 Sunday, September 15, 13
  9. 9. Requirement for a safe replacement a component at run-time • We assume that the corresponding off-line update is correct • The replacement is safe (correct) if • The transactions that end before the update satisfy the old specification S • The transactions that begin after the update satisfy the new specification S′ • The transactions that begin before the update, and end after it, satisfy either S or S′ 9 Sunday, September 15, 13
  10. 10. How can we safely replace a component at run-time? Different possible answers 1. when it is idle (not currently holding a transaction) 2. when it is quiescent 3. when it is tranquil 4. in such a way that all transactions are kept version consistent 10 Sunday, September 15, 13
  11. 11. How can we safely replace a component at run-time? Different possible answers 1. when it is idle (not currently holding a transaction) 2. when it is quiescent 3. when it is tranquil 4. in such a way that all transactions are kept version consistent 10 Sunday, September 15, 13
  12. 12. Replacing Auth when idle Portal Auth Proc DB getToken(cred) ✖ return  token B T1 process(token,  data) T0 verify(token) T3 OK Idle:   It  is  not  currently   hosting  transactions.   Sunday, September 15, 13 T2 dbOp() T4
  13. 13. Replacing Auth when idle Portal ✔ Auth C D T1 process(token,  data) T0 ✔ verify(token) T3 OK Idle:   It  is  not  currently   hosting  transactions.   Sunday, September 15, 13 DB getToken(cred) A return  token ✔ Proc T2 dbOp() T4
  14. 14. Replacing Auth when idle Portal Auth Proc DB getToken(cred) return  token ✔ C T1 Unsafe! process(token,  data) T0 verify(token) T3 OK T2 dbOp() T4 Sunday, September 15, 13
  15. 15. How can we safely replace a component at run-time? Different possible answers 1. when it is idle (not currently holding a transaction) 2. when it is quiescent 3. when it is tranquil 4. in such a way that all transactions are kept version consistent 12 Sunday, September 15, 13
  16. 16. How can we safely replace a component at run-time? Different possible answers 1. when it is idle (not currently holding a transaction) 2. when it is quiescent 3. when it is tranquil 4. in such a way that all transactions are kept version consistent 12 Sunday, September 15, 13
  17. 17. State of the art: Quiescence A node is quiescent if it is idle and the rest of the world has nothing to do with it Precisely (Kramer and Magee): 1. 2. 3. 4. it is not currently engaged in a transaction that it initiated it will not initiate new transactions it is not currently engaged in servicing a transaction no transactions have been or will be initiated by other nodes which require service from this node. J. Kramer, J. Magee The evolving Philosophers Problem: Dynamic Change Management, TSE 1990. 13 Sunday, September 15, 13
  18. 18. Achieving quiescence • To make a component quiescent, one need to passivate it and all components depending on it Auth Portal DB Proc 14 Sunday, September 15, 13
  19. 19. Achieving quiescence • To make a component quiescent, one need to passivate it and all components depending on it Auth Portal DB Proc 14 Sunday, September 15, 13
  20. 20. Achieving quiescence • To make a component quiescent, one need to passivate it and all components depending on it Auth Portal DB Proc 14 Sunday, September 15, 13
  21. 21. Achieving quiescence • To make a component quiescent, one need to passivate it and all components depending on it Auth Portal DB Proc 14 Sunday, September 15, 13
  22. 22. Replacing Auth when quiescent Portal ✖ Auth C D T1 process(token,  data) T0 ✖ DB getToken(cred) A return  token ✖ Proc verify(token) T3 OK T2 dbOp() T4 15 Sunday, September 15, 13
  23. 23. How can we safely replace a component at run-time? Different possible answers 1. when it is idle (not currently holding a transaction) 2. when it is quiescent 3. when it is tranquil 4. in such a way that all transactions are kept version consistent 16 Sunday, September 15, 13
  24. 24. How can we safely replace a component at run-time? Different possible answers 1. when it is idle (not currently holding a transaction) 2. when it is quiescent 3. when it is tranquil 4. in such a way that all transactions are kept version consistent 16 Sunday, September 15, 13
  25. 25. State of the art: Tranquility A node is tranquil if it is idle and it is not between two interactions with the same neighbor Precisely, (Vandewoude) 1. 2. 3. 4. it is not currently engaged in a transaction that it initiated, it will not initiate new transactions, it is not actively processing a request, and none of its adjacent nodes are engaged in a transaction in which it has both already participated and might still participate in the future. JI.Vandewoude et al. Tranquillity: A low-disruptive alternative to quiescence for ensuring safe dynamic updates, TSE 2007. 17 Sunday, September 15, 13
  26. 26. Replacing Auth when tranquil Portal Auth Proc DB getToken(cred) return  token T1 process(token,  data) T0 verify(token) T3 OK T2 dbOp() T4 18 Sunday, September 15, 13
  27. 27. Replacing Auth when tranquil Portal ✔ Auth Proc DB getToken(cred) A return  token T1 process(token,  data) T0 verify(token) T3 OK T2 dbOp() T4 18 Sunday, September 15, 13
  28. 28. Replacing Auth when tranquil Portal ✔ Auth Proc DB getToken(cred) A return  token T1 process(token,  data) T0 ✔ D verify(token) T3 OK T2 dbOp() T4 18 Sunday, September 15, 13
  29. 29. Replacing Auth when tranquil Portal ✔ Auth C D T1 process(token,  data) T0 ✔ DB getToken(cred) A return  token ✔ Proc verify(token) T3 OK T2 dbOp() T4 18 Sunday, September 15, 13
  30. 30. How can we safely replace a component at run-time? • Different possible answers 1. when it is idle ß Not enough! 2. when it is quiescent ß Safe, but can be disruptive 3. when it is tranquil ß Less disruptive, but can be unsafe 19 Sunday, September 15, 13
  31. 31. How can we safely replace a component at run-time? • Different possible answers 1. when it is idle ß Not enough! 2. when it is quiescent ß Safe, but can be disruptive 3. when it is tranquil ß Less disruptive, but can be unsafe 4. in such a way that all transactions are kept version consistent 19 Sunday, September 15, 13
  32. 32. How can we safely replace a component at run-time? • Different possible answers 1. when it is idle ß Not enough! 2. when it is quiescent ß Safe, but can be disruptive 3. when it is tranquil ß Less disruptive, but can be unsafe 4. in such a way that all transactions are kept version consistent 19 Sunday, September 15, 13
  33. 33. Version consistency • A criterion for dynamic reconfiguration of CBDSs • as safe as the Quiescence • more timely and less disruptive • We introduce a Distributed Management Algorithm to achieve VC for the component (or the part of the system) to be updated. X. Ma, L. Baresi, C. Ghezzi,V. Panzica La Manna, J. Lu.Version-consistent Dynamic Reconfiguration of Component-based Distributed Systems. FSE 2011 20 Sunday, September 15, 13
  34. 34. Version consistency Intuitively: any extant transaction, with all its (direct and indirect) subtransactions, is executed as if it were entirely in the old or entirely in the new configuration Transaction  T  is  version  consistent  with  respect  to  a  runtime  update   of  a  set  of  components  ω  with  a  new  version  ω′   iff                                                                                    .   A  runtime  update  is  version  consistent  iff  all  transactions  are  version   consistent  with  respect  to  the  update ext(T) = {x | x = T ∨ sub+ (T, x)} sub(T1,T2 ) T1 subtransaction of T2 21 Sunday, September 15, 13
  35. 35. Are the updates version consistent? Portal ✔ Auth C D T1 process(token,  data) T0 ✔ DB getToken(cred) A return  token ✖ Proc verify(token) T3 OK T2 dbOp() T4 22 Sunday, September 15, 13
  36. 36. Ensuring version consistency • Distributed runtime model of dynamic dependences • Freeness as a locally checkable condition • Methods for achieving freeness 23 Sunday, September 15, 13
  37. 37. Dynamic dependences Auth Portal DB Proc 24 Sunday, September 15, 13
  38. 38. Dynamic dependences To  serve  transactions  in  ext(T0), Portal  might  initiate  transactions   on  Auth  in  the  future Auth future T0 Portal DB Proc 24 Sunday, September 15, 13
  39. 39. Dynamic dependences To  serve  transactions  in  ext(T0), Portal  might  initiate  transactions   on  Auth  in  the  future Auth future T0 Portal Auth  has  hosted  transactions  in   ext(T0)  initiated  by  Portal  in  the   past DB past T0 Proc 24 Sunday, September 15, 13
  40. 40. Dynamic dependences future T0 To  serve  transactions  in  ext(T0), Portal  might  initiate  transactions   on  Auth  in  the  future past T0 Auth future T0 Auth  is  currently  hosting   transactions  in  ext(T0) Portal Auth  has  hosted  transactions  in   ext(T0)  initiated  by  Portal  in  the   past DB past T0 Proc 24 Sunday, September 15, 13
  41. 41. Dynamic dependences future T0 To  serve  transactions  in  ext(T0), Portal  might  initiate  transactions   on  Auth  in  the  future past T0 Auth future T0 Auth  is  currently  hosting   transactions  in  ext(T0) Portal Auth  has  hosted  transactions  in   ext(T0)  initiated  by  Portal  in  the   past DB past T0 It’s  a  distributed  runtime   model Proc 24 Sunday, September 15, 13
  42. 42. Valid configuration • A configuration with dynamic dependencies is a distributed runtime model - Dynamic dependences are represented by future and past edges created and removed at runtime - Each node is in charge of edges leaving from it and aware of edges entering it • A valid configuration must satisfy certain invariants on edges 25 Sunday, September 15, 13
  43. 43. Freeness Freeness is a locally checkable condition Given a configuration with dynamic dependence G, a component C is said to be free of dependence with respect to a root transaction T if there does not exist a pair of future/past edges labeled with T arriving at C A component is said to be free in G free of dependence A component is said to be free in G ififititisisfree of dependence by by all root transactions whose identifiers appearsin G appear in G. Freeness is sufficient for version consistency A dynamic update of a component is version consistent if it happens when the component is idle and free 26 Sunday, September 15, 13
  44. 44. Managing dynamic dependences The configuration with dynamic dependences is maintained at runtime, in a distributed way When a root transaction is started, a setup of all future edges is performed In practice, future edge information is stored locally Each node stores info about its incoming past and future edges Future edges are then eliminated and past edges created as the transaction is in progress A cleanup phase that eliminates remaining future/past edges is performed upon termination of the transaction. 27 Sunday, September 15, 13
  45. 45. 1) Setup (at the beginning of a rootTx): Recursively create enough future edges 28 Sunday, September 15, 13
  46. 46. 1) Setup (at the beginning of a rootTx): Recursively create enough future edges 29 Sunday, September 15, 13
  47. 47. 1) Setup (at the beginning of a rootTx): Recursively create enough future edges 30 Sunday, September 15, 13
  48. 48. 1) Setup (at the beginning of a rootTx): Recursively create enough future edges 31 Sunday, September 15, 13
  49. 49. 1) Setup (at the beginning of a rootTx): Recursively create enough future edges 32 Sunday, September 15, 13
  50. 50. 2) Progressing (on the beginning/ending subTxs): Progressively Remove Future Edges And Create Past Edges 33 Sunday, September 15, 13
  51. 51. 2) Progressing (on the beginning/ending subTxs): Progressively Remove Future Edges And Create Past Edges 34 Sunday, September 15, 13
  52. 52. 2) Progressing (on the beginning/ending subTxs): Progressively Remove Future Edges And Create Past Edges 35 Sunday, September 15, 13
  53. 53. 2) Progressing (on the beginning/ending subTxs): Progressively Remove Future Edges And Create Past Edges 36 Sunday, September 15, 13
  54. 54. 2) Progressing (on the beginning/ending subTxs): Progressively Remove Future Edges And Create Past Edges 37 Sunday, September 15, 13
  55. 55. 2) Progressing (on the beginning/ending subTxs): Progressively Remove Future Edges And Create Past Edges 38 Sunday, September 15, 13
  56. 56. 2) Progressing (on the beginning/ending subTxs): Progressively Remove Future Edges And Create Past Edges 39 Sunday, September 15, 13
  57. 57. 2) Progressing (on the beginning/ending subTxs): Progressively Remove Future Edges And Create Past Edges 40 Sunday, September 15, 13
  58. 58. 2) Progressing (on the beginning/ending subTxs): Progressively Remove Future Edges And Create Past Edges 41 Sunday, September 15, 13
  59. 59. 2) Progressing (on the beginning/ending subTxs): Progressively Remove Future Edges And Create Past Edges 42 Sunday, September 15, 13
  60. 60. 2) Progressing (on the beginning/ending subTxs): Progressively Remove Future Edges And Create Past Edges 43 Sunday, September 15, 13
  61. 61. 2) Progressing (on the beginning/ending subTxs): Progressively Remove Future Edges And Create Past Edges 44 Sunday, September 15, 13
  62. 62. 2) Progressing (on the beginning/ending subTxs): Progressively Remove Future Edges And Create Past Edges 45 Sunday, September 15, 13
  63. 63. 2) Progressing (on the beginning/ending subTxs): Progressively Remove Future Edges And Create Past Edges 46 Sunday, September 15, 13
  64. 64. 2) Progressing (on the beginning/ending subTxs): Progressively Remove Future Edges And Create Past Edges 47 Sunday, September 15, 13
  65. 65. 2) Progressing (on the beginning/ending subTxs): Progressively Remove Future Edges And Create Past Edges 48 Sunday, September 15, 13
  66. 66. 3) Clean-up (on the ending of RootTx ): Recursively remove past edges and remaining future edges 49 Sunday, September 15, 13
  67. 67. 3) Clean-up (on the ending of RootTx ): Recursively remove past edges and remaining future edges 50 Sunday, September 15, 13
  68. 68. Achieving freeness 1. Waiting for freeness to manifest itself (WF) • Low disruption, but no guarantee for timeliness. Freeness can be never achieved. 2. Using concurrent versions of the components (CV) • Our framework makes it easy to decide • Which version for which request, and • When the old version can retire. • Preferred If feasible. Timely and low disruptive. 3. Blocking transactions to achieve freeness (BF) • Timely, but more disruptive than WF/CV. 51 Sunday, September 15, 13
  69. 69. Evaluation • Goal: To evaluate timeliness and disruption • Compare our approach with the quiescence approach • Study the impact of network latency • Method: Discrete event simulations • Timeliness: time span between request and ready state • Disruption: loss of working time wrt. no reconfiguration 52 Sunday, September 15, 13
  70. 70. Experiment 1: Timeliness Our approach can be (~20%) more timely 53 Sunday, September 15, 13
  71. 71. Experiment 1: Disruption Our approach can be significantly less disruptive (~50% for BF and negligible for CV) 54 Sunday, September 15, 13
  72. 72. Experiment 2: Network Latency Our approach is consistently better in disruption but its gain in timeliness diminishes while message delay increases. 55 Sunday, September 15, 13
  73. 73. From components to a specification-based approach [ESEC/FSE 2011] X, Ma, L, Baresi, C, Ghezzi,V. Panzica La Manna, and J. Lu, “Version-consistent Dynamic Reconfiguration of Component-based Distributed Systems” [SEAMS 2012] C. Ghezzi, J. Greenyer,V. Panzica La Manna, "Synthesizing Dynamically Updating Controllers from Changes in Scenario-based Specifications" [SEAMS 2013] V. Panzica La Manna, , J. Greenyer, C. Ghezzi, C. Brenner, “Formalizing Correctness Criteria of Dynamic Updates Derived from Specification Changes” 56 Sunday, September 15, 13
  74. 74. Acknowledgements • • Most of the ideas discussed here matured or developed thanks to a funding from the European Research Council (Advanced Grant IDEAS-ERC, Project 227977---SMScom) ...and thanks to 57 Sunday, September 15, 13

×