On 04-Feb-14 11:16 AM, Greg Hurlman wrote: > Thanks Praveen for the reply. > > In my case, the applications are dependent on their instantiation as > well, forgot to mention and hence I have assigned the instantiation > level to components as C1=1, C2=2 and C3=3 etc. > At present surestart works like this: if instantiationlevel is like c1=1,c2=2 and c3=3 then during surestart, AMF will: 1) terminate c1 and instantiate it, 2)terminate c2 and instantiate it. 3)terminate c3 and instantiate it.
But according to 3.8.2 AMF B0401 spec: surestart should be done like this: 1) terminate c3, 2)terminate c2, 3)terminate c1 and then instantiate them in the reverse of above sequence. This test case, I think, still can be tried by reversing comp-inst level, if level is configured only as a means to limit the load on the system and actually does not represent any dependency resource wise. One more thing which redundancy model has been configured? What if fault of c2 gives c1 and c3 also some indication which they can use to halt/delay/quiesce their activity and when c2 gets instantiated then again all of them will get their work assignments, will it be useful for you.? Thanks, Praveen > Thanks, > Greg > > > > On Mon, Feb 3, 2014 at 9:01 PM, praveen malviya > <[email protected] <mailto:[email protected]>> wrote: > > > On 04-Feb-14 8:18 AM, Greg Hurlman wrote: >> Hi Praveen, >> >> For the SU restart, the configuration perfectly works. Thanks a lot. >> >> Only thing I noticed is while restarting the SU there is a >> unpredictable service still available on behalf of that SU. In >> the below scenario, where c1, c2, c3 are the components present >> in SU with CSI dependencies among them is c3->c2->c1 and c2 >> faults. On c2 fault, the component restart oder in SU is >> c1->c2->c3. So c3 waits for restart until its order comes and >> ends up in providing unpredictable service to the external world. >> This is because c1, c2 and c3 are expected to be running >> concurrently to provide a predictable service. I say >> unpredictable as c3 alone can not provide service without c1 and >> c2 running without any fault. >> >> So the problem in the current case is that, SU restart takes >> total 5 secs say. During restart of the components in SU, c1 is >> restarted first and c3 at last. So c3 being unaware of the fact >> that c2 has already faulted, continue to provide unpredictable >> service for 5 secs say. >> Hence, wouldn't it be correct if we stop the components c1, c2, >> and c3 first(like a admin lock on SU) to prevent SU to provide >> any service and then start the components in the order of CSI >> dependencies, instead of the current way of just restarting them. >> >> > This is an existing issue which is not fixed yet #315. This is > actually referred as termination of components should be done > honoring comp-instantiation level. > In case of lock-in operation it is honored correctly. In this > application, do all these components have dependencies because > execution environment. If not it means > only dependencies is because of assignments. Since assignments > will always happen after su has restarted, can you test your > application by configuring comp-instantiation level > for the components such that inst-level will be for c1=3, c2=2 and > c3=1. > > Thanks > Praveen > >> Thank you again >> Greg >> >> >> On Mon, Jan 27, 2014 at 11:32 PM, praveen malviya >> <[email protected] <mailto:[email protected]>> >> wrote: >> >> >> On 27-Jan-14 11:09 AM, Greg Hurlman wrote: >> >> Hi, >> >> Can somebody help me understand how to configure for the >> below scenarios. >> >> 1. I want to do a service unit restart when a contained >> component faults in >> case of a "no redundancy model" with no spare SUs. I do >> not want the faulty >> component just restarts in case it faults rather all the >> contained >> components in that SU. Is it possible through component >> recovery options? >> Also a node reboot is not desired. >> >> For surestart recovery: >> saAmfSgtDefCompRestartMax=0 >> saAmfSgtDefSuRestartMax=2(say) >> saAmfCtDefRecoveryOnError=2 >> saAmfCtDefDisableRestart=0 >> >> >> >> 2. How would we monitor the SU as a whole or to know the >> health status of >> the SU just like we do for the SA aware component? Does >> AMF or CLM supports >> such configuration? Are there any alternatives? >> >> Appreciate for any input in this regard. >> >> I did not get the question completely. But I think referring >> to section 11.2.2 of AMF B0401 spec can help. >> This section talks about the "State Change Notifications" >> that AMF sends when SU or node and other such entities are >> affected. >> An application can subscribe with Notification service to >> monitor these notifications. In case of SU alarms are sent >> for admin,operational and presence state change etc. >> I think this is what is meant by the health of SU. >> >> >> Thanks >> Praveen >> >> Thanks, >> Greg >> >> ------------------------------------------------------------------------------ >> CenturyLink Cloud: The Leader in Enterprise Cloud Services. >> Learn Why More Businesses Are Choosing CenturyLink Cloud For >> Critical Workloads, Development Environments & Everything >> In Between. >> Get a Quote or Start a Free Trial Today. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >> _______________________________________________ >> Opensaf-users mailing list >> [email protected] >> <mailto:[email protected]> >> https://lists.sourceforge.net/lists/listinfo/opensaf-users >> >> >> > > ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk _______________________________________________ Opensaf-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-users
