Thanks Mathi, Comments inline...
On Oct 12, 2015, at 2:37 AM, Mathivanan Naickan Palanivelu <[email protected]<mailto:[email protected]>> wrote: To add on, Please find comments inline: -----Original Message----- From: Anders Björnerstedt [mailto:[email protected]] Sent: Monday, October 12, 2015 11:31 AM To: Tony Hart; [email protected]<mailto:[email protected]> Subject: Re: [users] Avoid rebooting payload modules after losing system controller It sounds to me as if you can accept one controller (current situation) or possibly three or four. But *two* controllers I not allowed. Why is two a magic bad number ? The "cost savings" (if any) would disappear with 3 or 4 controllers also, would it not ? In addition, in the headless state that you will be in with no controller may have saved you some hardware cost, but it has the downside of losing the cluster level service availability support. Bottom line is you will get reduced service availability (that’s a statistical parameter). Off the shelf hardware is amazingly cheap, typically insignificant in relation to the cost of a service outage, for both the customer and the provider of the platform. /Anders Bjornerstedt -----Original Message----- From: Tony Hart [mailto:[email protected]] Sent: den 11 oktober 2015 14:31 To: [email protected]<mailto:[email protected]> Subject: [users] Avoid rebooting payload modules after losing system controller We have been using opensaf in our product for a couple of years now. One of the issues we have is the fact that payload cards reboot when the system controllers are lost. Although our payload card hardware will continue to perform its functions whilst the software is down (which is desirable) the functions that the software performs are obviously not performed (which is not desirable). Why would we loose both controllers, surely that is a rare circumstance? Not if you only have one controller to begin with. Removing the second controller is a significant cost saving for us so we want to support a product that only has one controller. The most significant impediment to that is the loss of payload software functions when the system controller fails. OpenSAF does not imposes any additional hardware requirements on the controllers than on the payloads. Therefore you can run your applications on the controller nodes! To avoid SPOF you would of course design and deploy atleast a two node cluster in which case both of them controller nodes hosting applications! You may then keep adding additional nodes(termed payloads) based on your requirements [TH] right. That would be an option. In the single-server system the server would be one of the “system-controllers” and one of the LineCard would be the other. It gets logistically tricky to select the LineCard since one or other (or both) may not be there. This is the origin of the request to have 3-system-controllers, I would make Server, LineCard1 and LineCard2 all be system-controllers at system startup. I’m looking for suggestions from this email list as to what could be done for this issue. One suggestion, that would work for us, is if we could convince the payload card to only reboot when the controller reappears after a loss rather than when the loss initially occurs. Is that possible? You could try customizing the opensaf_reboot script! [TH] ok good. Lets say I customize it to not reboot but continue. What state would the OSAF processes be in at that point? If my processes try and use some osaf functions would they get error’s returned or hangs? Another possibility is if we could support more than 2 controllers, for example if we could support 4 (one active and 3 standbys) that would also provide a solution for us (our current payloads would instead become controllers). I know that this is not currently possible with opensaf. Without ruling out support for multiple controllers(in the future), could you Explain the usecase scenario behind this? What is the requirement driving you For this? [TH] I think I covered this above and in reply to Anders email, if not let me know, I’ll try again:-) Thanks, Mathi. thanks for any suggestions, — tony ------------------------------------------------------------------------------ _______________________________________________ Opensaf-users mailing list [email protected]<mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/opensaf-users ------------------------------------------------------------------------------ _______________________________________________ Opensaf-users mailing list [email protected]<mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/opensaf-users ------------------------------------------------------------------------------ _______________________________________________ Opensaf-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-users
