Having problems with your account or logging in?
A lot of changes are happening in the community right now. Some may affect you. READ MORE HERE

override CSA asynchonous provisioning of multiple servers

override CSA asynchonous provisioning of multiple servers

CSA needs an option to change the default behavior of all server builds in a server group being launched asynchronously.  This really causes contention with accessing shared resources like IP Address Management, etc.   The only way to work around this issue currently is to use semiphores which have their own issues. 

There really should be a way to make server builds queue up in CSA and build serially.  The server group components are processed serially, so it makes sense to give the option of having the server components build serially too.   

It would also be nice if there was some sort of internal CSA property (i.e. SVC_Component_Instance) that corresponds to server build order so that if you need to process an operation on only the first server, or only the last server there was a way to track programatically which server number is currently being built.

4 Comments
Micro Focus Expert
Micro Focus Expert

I think the proper aproach to solve problems with  "contention with accessing shared resources" is based on operations in OO; I've implemeted in the past without problems, exactly for IPAM with the OO lock operation. 

Just serialize the request in many scenarios means a much longer total provisioning time (like allow up to 5 vm clonning in parallel on same vcenter); also restrict only in single subscription server group, leaves out of control other requests coming from other users; maybe you can think on restrict on provider level, but again this has many collateral limitations.


Other topic is limitations of OO lock operation as detailed https://community.microfocus.com/t5/Operations-Orchestration-Idea/Real-OO-Semaphore-operations/idi-p/1635598 specially on comment by @David Fidler

 

jgrummons Contributor.
Contributor.

Yes, the limitations of the OO lock operation (semaphors) is precisely why that is not a good solution.  They are not re-entrant and they don't seem to work well accross clustered OO servers.  I ended up having to write my own semaphore flows that used a third party solution for storing the lock files.

I agree that some users may have concerns about total provisioning time which is why i'm suggesting serial provisioning be an option, not a default.  

Semaphores are problematic because if locks don't get removed due to errors they can cause issues.  A native queueing mechanism  mitigates the need for semaphores.  IPAM is not the only shared resource scenario this makes a lot of sense for.   Azure availability sets is another good example.  You only need to create one for the first server of a set, but it's a race to determine which one that is in paralell provisioning.  So, you end up having to code around that with sleeps operations or lock files, but again, not always reliable. 

I hate to call out a competing product, but VMware vRealize Automation Event Broker is an excellent example of how this could work.

Micro Focus Frequent Contributor
Micro Focus Frequent Contributor
Status changed to: Waiting for Votes
 
Micro Focus Contributor
Micro Focus Contributor

Hi @jgrummons 

I would like to understand this requirment a bit more.

In your service design you want to use server group  with pattern component under it and also do not want the components created under server group component to be processed in parallel (as Ramon pointed out the reason for parallelism is to allow concurrent processing to improve provisioning throughput).

We do have a mechanism to define exact sequence of processing explicitely, but NOT for pattern component. In case of pattern component we do not know how many comonents will be instantiated ahead of time, hence you can't order them, but I believe you are asking to have a configuration to provision those components sequentially, one at a time, w/o giving any control to define specific order of execution of the instantiated components, individually.

I want to confirm the motivation for using pattern component in the first place - is it because you want the number of servers to be specified at the time of ordering, but at the same time in your service implementation you do not want to deal with synchronization needed (which would be different for different service and HCM should not have any assumed knowledge of it), so you just want to go for serialized provisioning (which can make the overall provisioning time higher)? Please confirm / clarify.

I have seen quite a few customer designs where parallel execution is needed / desired, and parallel execution is more complex to build out than having only serialized processing, but I can see your rationale to allow sequential execution so that as a service implementer you don't have to deal with complexity when you don't care about service provisioning throughput.

Regards,

Nivedita

 

 

 

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.