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]
> 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]
> 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

> 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!

> 
> 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?

Thanks,
Mathi.

> 
> thanks for any suggestions,
> —
> tony
> ------------------------------------------------------------------------------
> _______________________________________________
> Opensaf-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/opensaf-users
> ------------------------------------------------------------------------------
> _______________________________________________
> Opensaf-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/opensaf-users

------------------------------------------------------------------------------
_______________________________________________
Opensaf-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-users

Reply via email to