...
When a request is broadcast on DMaaP, the request is asynchronously picked up by participants of the types required for the 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 it controls, together with statistics on the Control Loop Elements over DMaaP. On reception of these participant messages, the CLAMP runtime stores this information to its database.
The CLAMP runtime periodically runs a supervision function, which checks the status of all existing Control Loop Instances and the status of outstanding requests. It builds a picture of the current status of each Control Loop Instance from the reports on the elements of the Control Loop Instances. Once the CLAMP runtime has a full picture, it checks that each Control Loop Instance is in the correct state as requested by the user of the system. If a Control Loop Instance is not in the correct state, the supervision function can initiate actions such as performing retries on operations or issuing alarms or notifications on that Control Loop Instance.participant to use on a control loop can be selected from the registered participants in either of two ways:
- Runtime-side Selection: The CLAMP runtime selects a suitable participant from the list of participants and sends the participant ID that should be used in the Participant Update message. Int his case, the CLAMP runtime decides on which participant to use based on a suitable algorithm. Algorithms could be round robin based or load based.
- Participant-side Selection:
This approach makes it easy to scale Control Loop life cycle management. As Control Loop Instance counts increase, more than one CLAMP runtime can be deployed and REST/supervision operations on Control Loop Instances can run in parallel. The number of participants can scale because an asynchronous broadcast mechanism is used for runtime-participant communication and there is no direct connection or communication channel between participants and CLAMP runtime servers. Participant state, Control Loop Instance state, and 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 Loop Instances of many types across themselves using a mechanism such as a Kubernetes cluster.
...