1. A Model-Based Approach for AMF Configuration Generation Pejman Salehi, Pietro Colombo Abdelwahab Hamou-Lhadj, Ferhat Khendek Concordia University Department of Electrical and Computer Engineering SAM 2010 Oslo Norway October 5 th

2. Outline  Introduction  Availability Management Framework (AMF) ▫AMF configurations  AMF configuration design  Model based configuration generation  Conclusion 2

3. Introduction (High Availability) AvailabilityDowntime per Year 90%36.5 days 99%3.7 days 99.9%9 hours 99.99%53 min 99.999%5 min 99.9999%32 sec 3 High Availability: At least 99.999 % (a.k.a. five nines) Availability is the probability that when a service is requested, it will be provided

4. Introduction (Availability Management)  Platform specific solution ▫HPMC/Serviceguard and SunCluster: detect nodes that fail and automatically failover application components to surviving nodes  Platform independent solution (Middleware) ▫Using the best practices from different platforms and domains ▫Portability 4

5. Service Availability Forum (SA Forum)  It is a consortium of industry-leading communications and computing companies working together to develop and publish high availability and management software interface specifications  It has defined a set of standardized services for high- availability ▫To enable portability and reusability across different platforms by shifting the availability management from applications to a dedicated middleware 5

6. Availability Management Framework (AMF)  AMF is the middleware part responsible for managing the availability of the services provided by an application ▫Managing the redundant components of the application by dynamically shifting workloads of faulty components to healthy components  An AMF configuration for a given application is a logical organization of resources for providing and protecting services 6

7. AMF Configuration (example) 7 APT-A SGT-A SUT-A CT-ACT-B SVCT-A CST-ACST-B Node 1Node2 App1 (APT-A) SG1 (SGT-A) SU2 (SUT-A) SU1 (SUT-A) Component3 (CT-A) Component4 ( CT-B) Component1 (CT-A) Component2 (CT-B) SI2 (SVCT-A) CSI3 (CST-A) CSI4 (CST-B) SI1 (SVCT-A) CSI1 (CST-A) CSI2 (CST-B) Runtime According to : Redundancy Model Component: is a logical entity that represent a set of resources (hardware and/or software) to AMF. Service unit: is a logical entity that represents a set of components that collaborate to provide a certain service. Service group: is a group of service units that provide service availability to a set of service instances Application: is a set of service groupsComponent service instance: is a abstraction of the service provided by the component. Service instance: is a abstraction of the service provided by the service unit. Node: Represents a computational resource for the deployment. AMF entity types: are data structures that define the common characteristics among multiple instances of entities.

8. AMF Configuration Design 8 Service Description Infrastructure Description AMF Configuration Generator AMF Configuration Software Description Protection Level Entity Types File (ETF) Configuration Requirements SUT-AA CT-AACT-BB SVCT-AA CST-AACST-BB depends A/S 23 SITemp1 #Sis = 1 Svct = SVCT-AA RM = 2N # Active SUs = 1 CSITemp1 #CSIs =2 CST = CST-AA CSITemp2 #CSIs =2 CST = CST-BB depends NodeTemp1 #Nodes = 2 Cluster1

9. AMF Configuration Design Challenges  The large number of entities and the numerous parameters (50 domain concepts and over 250 parameters)  The complexity of the concepts and their relationships defined in the AMF configuration domain (two level of abstraction)  The large number of constraints imposed by the domain (89 domain constraints)  The dynamic aspects of the AMF configurations  The ambiguity of the existing specifications in describing AMF configurations 9

10. AMF Configuration Design  The manual or ad hoc approach is extremely tedious and error prone  It is necessary to have a systematic approach to the design of the AMF configurations ▫Dealing with the problem at the proper level of abstraction ▫Comprehensively specify the domain specific artefacts ▫Thoroughly define the required processes 10

11. Model-Driven Paradigm  Focuses on models and abstractions which are closer to the domain concepts  Shifts from the level of details to a higher level of abstraction  Increases efficiency, serviceability, quality and flexibility 11

12. Model based AMF Configuration Generation 12 Modeling Framework for AMF Configuration Management Entity Type Files Profile AMF Profile Entity Type Files Model AMF Configuration Model > Configuration Requirements Profile Configuration Requirements Model > Model Based AMF Configuration Generation

13. Model based AMF Configuration Generation 13 ETF Type Selection AMF Entity Creation AMF Type Creation Entity Type Files Model Configuration Requirements Model Selected ETF Model + Configuration Requirements Model AMF Types Model + Configuration Requirements Model AMF Configuration Model ETF Profile CR Profile AMF Profile ETF Profile CR Profile AMF Profile CR Profile >

14. Selecting Software Entities 14 SITemp1 #Sis =2 Svct = SVCT-AA RM = 2N # Active SUs = 1 CSITemp1 #CSIs =1 CST = CST-AA CSITemp2 #CSIs =1 CST = CST-BB SUT-AA CT-AACT-BB SVCT-AA CST-AACST-BB SVCT-CC CST-CC CT-CC SVCT-BB depends CT-DD SUT-CC A/S A 23 Supporting the required services Capable of supporting the required Redundancy ModelCompliance with software capabilities and limitationsCompliance with software dependency Selecting the appropriate software entities capable of satisfying requirements

15. Model based AMF Configuration Generation 15 ETF Type Selection AMF Entity Creation AMF Type Creation Entity Type Files Model Configuration Requirements Model Selected ETF Model + Configuration Requirements Model AMF Types Model + Configuration Requirements Model AMF Configuration Model ETF Profile CR Profile AMF Profile ETF Profile CR Profile AMF Profile CR Profile >

16. Design of the Type level Configuration Entities 16 SITemp1 #Sis = 1 Svct = SVCT-AA RM = 2N # Active SUs = 1 CSITemp1 #CSIs =2 CST = CST-AA CSITemp2 #CSIs =2 CST = CST-BB SUT-AA CT-AACT-BB SVCT-AA CST-AACST-BB depends A/S 23 2N APT-A SGT-A SUT-A CT-ACT-B SVCT-A CST-ACST-B  Creating AMF Types from ETF Types  Creating AMF Types missing from ETF  Configuring the attributes  Multiple scenarios and extension point for quality attributes such as cost

17. Model based AMF Configuration Generation 17 ETF Type Selection AMF Entity Creation AMF Type Creation Entity Type Files Model Configuration Requirements Model Selected ETF Model + Configuration Requirements Model AMF Types Model + Configuration Requirements Model AMF Configuration Model ETF Profile CR Profile AMF Profile ETF Profile CR Profile AMF Profile CR Profile >

18. Design of the instance level Configuration Entities 18 Node 1Node2 App1 (APT-A) SG1 (SGT-A) SU2 (SUT-A) SU1 (SUT-A) Component3 (CT-A) Component4 ( CT-B) Component1 (CT-A) Component2 (CT-B) SI2 (SVCT-A) CSI3 (CST-A) CSI4 (CST-B) SI1 (SVCT-A) CSI1 (CST-A) CSI2 (CST-B) SITemp1 #Sis = 1 Svct = SVCT-AA RM = 2N # Active SUs = 1 CSITemp1 #CSIs =2 CST = CST-AA CSITemp2 #CSIs =2 CST = CST-BB depends  Creating AMF Service Entities  Creating AMF Service Provider Entities  Create the Structure of the Configuration  Creating the Deployment Entities  Configuring the attributes NodeTemp1 #Nodes = 2 Cluster1 APT-A SGT-A SUT-A CT-ACT-B SVCT-A CST-ACST-B

19. Model based AMF Configuration Generation (Advantages)  Increases the level of abstraction at which the configuration designer has to specify configuration properties, abstracting away unnecessary details  Using declarative style transformation rules abstract from the operational steps  The model-driven configuration generation process is based on our newly created UML profile and can be embedded in any UML CASE tool  The approach is based on standards, namely UML, OCL, and ATL  Extendibility of the approach 19

20. Questions? 20

21. 21

22. 22

23. Entity Types File (ETF)  ETF is an SA Forum standard used to capture the description of the software  ETF represents: ▫The comprehensive description of the software’s components ▫The capabilities of the software ▫The services that can be supported by components ▫The limitation of the software components ▫Software dependencies and compatibility options ▫How the software’s components can be combined  ETF is provided by the software developer 23 SUT-AA CT-AACT-BB SVCT-AA CST-AACST-BB depends A/S 23