Please see response inline with [Praveen]. Thanks, Praveen
On 17-Oct-16 11:46 PM, David Hoyt wrote: > Hi all, > > I'm encountering a scenario where opensaf shows the HA state of both SUs > within a 2N redundancy Service Group as standby. > Setup: > > - Opensaf 4.6 running on RHEL 6.6 VMs with TCP > > - 2 controllers, 4 payloads > > - SC-1 & SC-2 are the VMs with the controller nodes (SC-1 is active) > > - PL-3 & PL4 have SU1 & SU2 from SG-A (2N redundancy) > > - PL-5 & PL-6 have SU1 & SU2 from SG-B (2N redundancy) > > - Server-1 has three VMs consisting of SC-1, PL-3 and PL-5 > > - Likewise, server-2 has SC-2, PL-4 and PL-6 > > I reboot server 1 and shortly afterwards, the SG-A SUs begin to failover. SU2 > on PL-4 goes active. > Around the same time, the opensaf 2N SUs failover. > After the dust has settled, and server-1 comes back as well as the VMs, all > appears fine except the SG-A SUs. They both have a standby HA state. > > Is there any way to correct this? [Praveen] I think there is no issue from the callback perspectives as SU2 on PL-4 was made active(comps received callbacks). Only problem is outout of "amf-state siass". Please share AMFD traces from both the controller. > Is there some audit that periodically checks the validity of the HA states? > > Now, when SG-A, SU1 recovers, I did swact the SUs and it corrected the HA > state. However, if server-1 goes down for an extended period, the HA state of > SG-A, SU2 will appear as Standby, when it's actually running as active. > > > Before the reboot: > > [root@sc-2 ~]# amf-state siass | grep -A 2 OpenSAF | grep -A 1 safSg=2N > safSISU=safSu=SC-1\,safSg=2N\,safApp=OpenSAF,safSi=SC-2N,safApp=OpenSAF > saAmfSISUHAState=ACTIVE(1) > -- > safSISU=safSu=SC-2\,safSg=2N\,safApp=OpenSAF,safSi=SC-2N,safApp=OpenSAF > saAmfSISUHAState=STANDBY(2) > [root@jenga-56-sysvm-1 ~]# > [root@sc-2 ~]# amf-state siass | grep -A 1 SG-A > safSISU=safSu=SU2\,safSg=SG-A\,safApp=SG-A,safSi=SG-A,safApp=SG-A > saAmfSISUHAState=STANDBY(2) > -- > safSISU=safSu=SU1\,safSg=SG-A\,safApp=SG-A,safSi=SG-A,safApp=SG-A > saAmfSISUHAState=ACTIVE(1) > [root@sc-2 ~]# > [root@sc-2 ~]# amf-state siass | grep -A 1 SG-B > safSISU=safSu=SU2\,safSg=SG-B\,safApp=SG-B,safSi=SG-B,safApp=SG-B > saAmfSISUHAState=STANDBY(2) > -- > safSISU=safSu=SU1\,safSg=SG-B\,safApp=SG-B,safSi=SG-B,safApp=SG-B > saAmfSISUHAState=ACTIVE(1) > [root@sc-2 ~]# > > > > After the reboot: > [root@sc-2 ~]# amf-state siass | grep -A 2 OpenSAF | grep -A 1 safSg=2N > safSISU=safSu=SC-1\,safSg=2N\,safApp=OpenSAF,safSi=SC-2N,safApp=OpenSAF > saAmfSISUHAState=STANDBY(2) > -- > safSISU=safSu=SC-2\,safSg=2N\,safApp=OpenSAF,safSi=SC-2N,safApp=OpenSAF > saAmfSISUHAState=ACTIVE(1) > [root@sc-2 ~]# > [root@sc-2 ~]# amf-state siass | grep -A 1 SG-A > safSISU=safSu=SU1\,safSg=SG-A\,safApp=SG-A,safSi=SG-A,safApp=SG-A > saAmfSISUHAState=STANDBY(2) > -- > safSISU=safSu=SU2\,safSg=SG-A\,safApp=DVN,safSi=SG-A,safApp=SG-A > saAmfSISUHAState=STANDBY(2) > [root@sc-2 ~]# > [root@sc-2 ~]# amf-state siass | grep -A 1 SG-B > safSISU=safSu=SU2\,safSg=SG-B\,safApp=SG-B,safSi=SG-B,safApp=SG-B > saAmfSISUHAState=ACTIVE(1) > -- > safSISU=safSu=SU1\,safSg=SG-B\,safApp=SG-B,safSi=SG-B,safApp=SG-B > saAmfSISUHAState=STANDBY(2) > [root@sc-2 ~]# > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Opensaf-users mailing list > Opensaf-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/opensaf-users > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Opensaf-users mailing list Opensaf-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-users
