Hi Anders, Thanks for the response, please see comments in line... > On Oct 12, 2015, at 2:00 AM, Anders Björnerstedt > <[email protected]> wrote: > > 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 ?
[TH] yes I wasn’t very clear. I wasn’t referring to the hardware rather its the software role of “system-controller” versus “payload” that I want to change. For example my system's hardware might comprise (Server, LineCard1, LineCard2). Normally “Server” would be a controller and “LineCardx” would be payloads. This leads to the SPOF if the Server fails. [TH] If instead I could also make LineCard1 and LineCard2 perform the “system-contoller” role then I will always have at least one system-controller in the system and I have reduced the cost of the system by not requiring a “Server2” card. > > The "cost savings" (if any) would disappear with 3 or 4 controllers also, > would it not ? [TH] yes, but as explained above I would take the existing payload hardware and have it perform the role of “system-controller”. So no addition Server hardware needed. > > 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. [TH] agreed that some functionality will be lost but this is assumed to be a temporary situation whilst a replacement Server card is procured and installed. Expected to be a few days only. > 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. [TH] As I explained the hardware is not cheap, that’s the reason why there is objection to having two Servers. It is the "unnecessary service outage" that is the issue here, because of the fact that it is unnecessary. The hardware on the LineCard can continue to perform its function without the sw running, however we unnecessarily lose the sw functions the LineCard provides when the Server is down. This loss of sw function is hard to justify. > > /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. > > 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? > > 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. > > 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
