...
5. Non Functional Considerations
5.1 Upgrade
Performing a hot upgrade of the Control a Control Loop Instance at run time as well as handling an upgrade of the software in one or more of the participants in an Control Loop is a particularly challenging issue because upgrading must handle the following cases without tearing down the Control Loop:
- Upgrade and changes of the configuration data of participants
- Addition of or removal of participants in an Control Loop
- Upgrade of software in one or more participants in an Control Loop
- Maintenance of compatibility between participants when an update of more than one participant must be done together to ensure compatibility, for example, when a protocol being used by two participants to communicate is upgraded
5.2 Scalability
The system is designed to be inherently scalable. The control loop CLAMP runtime server is stateless, all state is preserved in the run time inventory in the database. When the user requests a control loop an operation ( such as an instantiation, activation, passivation, or an ininitialization) the server uninitialization on a Control Loop Instance, the CLAMP runtime broadcasts the request to participants over DMaaP and saves details of the request to the database. The server The CLAMP runtime does not directly wait for responses to requests.
When a request is broadcast on DMaaP, the request is asynchronously picked up by participants of the types required for the control loop instance Control Loop Instance and those participants manage the life cycle of its control loop elements. Periodically, each participant reports back on the status of operations it has picked up for the control loop elements Control Loop Elements it controls, together with statistics on the control loop elements the Control Loop Elements over DMaaP. On reception of these participant messages, the server CLAMP runtime stores this information to its database.
The server CLAMP runtime periodically runs a supervision function, which checks the status of all existing control loop instances Control Loop Instances and the status of outstanding requests. It builds a picture of the current status of each control loop instance Control Loop Instance from the reports on the elements of the control loop instancesControl Loop Instances. Once the server the CLAMP runtime has a full picture, it checks that the control loop instance each Control Loop Instance is in the correct state as requested by the user of the system. If the control loop a Control Loop Instance is not in the correct state, the supervision function can initiate actions such aas as performing retries on operations or issuing alarms or notifications on control loop instancesthat Control Loop Instance.
This approach makes it easy to scale control loop LCM. As control loop instance Control Loop life cycle management. As Control Loop Instance counts increase, more than one CLAMP runtime server can be deployed and REST/supervision operations on control loop instances Control Loop Instances can run in parallel. The number of participants can scale because an asynchronous broadcast mechanism is used for serverruntime-participant communication and there is no direct connection or communication channel between participants and CLAMP runtime servers. Participant state, control loop instance Control Loop Instance state, and control loop element Control Loop Element state is held in the database, so any CLAMP runtime server can handle operations for any participant. Because many participants of a particular type can be deployed and participant instances can load balance control loop element instances for different control loops Control Loop Instances of many types across themselves using a mechanism such as a Kubernetes cluster.
...
The design and implementation of TOSCA Control Loops in CLAMP is described for each executable entity on the pages below:
...