Generating AMF compliant configurations is a tedious and error prone task. We can mitigate this complexity through automation. Nonetheless we need to make sure the compliancy is captured throughout the automation process. In this section we discuss this issue as well as other challenges that we faced in during the automation of configuration generation.
79
4.6.1 Compliancy with the AMF Specifications
Beginning with the input, we defined various OCL constraints on the CR model to ensure that the input is consistent and complete. Within the context of our project, the authors in [22] defined a UML domain model that restructures the standard AMF configuration model and annotates it with over 90 OCL constraints that capture and further refine AMF concepts and constraints from the standard specification. This domain model, including all the OCL constraints, has been used as a basis for the design and implementation of a configuration validation tool [24], which was used in different sub-projects in the group to validate generated or third party provided configurations.
For ensuring compliance by construction with the standard, several of the constraints in the domain model were implicitly embedded directly into our configuration generation algorithms (e.g. the constraint specifying the allowed component capability model to be used with a certain redundancy model). However we could not embed directly all of these constraints into our method. This is mainly because of the large scope that certain constraints have. Such a scope can spread over several types and entities. Such constraints can only be invoked after the configuration is generated and not during the generation. For validating our configuration generation technique, we checked the compliance of our generated configurations to the standard using the validator. We defined a test plan in which we generated and checked various configurations that include various corner cases and typical cases.
80
4.6.2 Selection of Orphan Types
The selection of an orphan type requires the population of the attributes of the created parent type. These attributes may require a good understanding of the software implementation and therefore may not be derived automatically. An example of such a type attribute is the component restart probation period found in an SG type. This attribute applies to components in service units belonging to a service group of this type. If the AMF SG type is created (instead of being derived from ETF) then this attribute needs to be determined without any guidance from the vendor. We need to introduce artificially a value, which will affect the software behavior at runtime and therefore impacts the quality of the generated configuration. It is still unclear how to determine safely the attributes of the different entity types when they are created.
A related observation is that it is necessary to maintain the information whether a type was created by our method or provided by the software vendor in the ETF. Created types do not reflect implementation limitation and therefore should not restrict the use of orphan types. However they may be reused whenever they are appropriate to ease the type creation task.
4.6.3 Selection of Higher Level Types
In the single configuration generation approach, our preference is to only analyze orphan types when the non-orphan ones have been checked and found unsatisfactory with respect to the configuration requirements. However, there might be situations where we have an ETF (or multiple ETFs) where more than one type can be a candidate. This is typically the case for different versions of software or that offers similar services but provided by
81
different vendors. Some vendors (versions) may constrain the way their components should be configured by having the corresponding component types refer to SU types, while other vendors may provide components that do not need to be constrained from the ETF perspective. In other words, the component types corresponding to these components are orphans. Depending on the required services and the deployment system, there might be situations where orphan component types are a better choice than non- orphan types due to their flexibility. This comes at the price of the difficulties of type creation as aforementioned. Our technique is easily adaptable to select types in any desirable order.
4.6.4 Multiple Configuration Generation
Multiple configuration generation is a more complicated process than the one generating single configurations. This complexity is not only limited to defining the process but also to executing it. For instance while the algorithms for single configuration generations have a polynomial time complexity, in multiple configuration generation this complexity becomes exponential. In addition, having multiple configurations without the proper metrics to evaluate them is impractical. With highly available systems it is extremely important to be able to characterize a system configuration with the level of availability it offers to its services. In Chapter 6 we define an approach to evaluate the service availability of a given AMF configuration which enables us to compare AMF configurations and select the one that best satisfies our requirements.
82
5 Workload Balancing through
AMF Configurations
In this chapter we target the issue of workload balancing through the information specified in the AMF configuration. More specifically we want to make sure that at runtime, AMF will equally distribute the SIs among SUs, and in case a failure occurs, we want to keep this workload assignment balanced.
The contributions discussed in this chapter are as follows:
(1) Defining an approach for workload balancing in NwayActive redundancy model and discuss its applicability to Nway.
(2) Defining an approach for workload balancing in N+M redundancy models