Hi, (off-list)
Long time ago I was asked to change terms "headless" and "hydra" with "SC absence", and I did this change. I couldn't find the email where I was told that. I'll see if I will able to find it. In README file, "SC absence" term is used, and in this document it's used "headless" term. I would like to use one term in documents. For us, we understand that "SC absence" and headless is the same, but it might not be the case with OpenSAF users. On the other hand, I see that other services, like LOG, use "headless" term in the documentation. Any opinion regarding this ? Should we go with one term instead of using more terms ? Beside this comment, the patch is ok. Thanks, Zoran -----Original Message----- From: Hung Nguyen [mailto:[email protected]] Sent: den 25 juli 2016 12:58 To: Zoran Milinkovic; [email protected] Cc: [email protected] Subject: [PATCH 1 of 1] imm: Add readme for headless feature [#1856] osaf/services/saf/immsv/README | 2 + osaf/services/saf/immsv/README.HEADLESS | 72 +++++++++++++++++++++++++++++++++ 2 files changed, 74 insertions(+), 0 deletions(-) Add readme for headless feature. diff --git a/osaf/services/saf/immsv/README b/osaf/services/saf/immsv/README --- a/osaf/services/saf/immsv/README +++ b/osaf/services/saf/immsv/README @@ -2779,6 +2779,8 @@ provided during absent SC depends on the of the IMM service, the service provided during SC absence is in essence only the reading of config data. +See: osaf/services/saf/immsv/README.HEADLESS for details. + Add attribute definition flag SA_IMM_ATTR_STRONG_DEFAULT (5.0) =============================================================== diff --git a/osaf/services/saf/immsv/README.HEADLESS b/osaf/services/saf/immsv/README.HEADLESS new file mode 100644 --- /dev/null +++ b/osaf/services/saf/immsv/README.HEADLESS @@ -0,0 +1,72 @@ +HEADLESS: Allow IMMNDs to survive SC absence (5.0) +================================================= +Prior to this enhancement, absence of both SCs will cause IMMNDs to +restart, also the cluster will be reboot by AMF. With this feature, +IMMNDs on payloads continue to provide limited service until an SC is back. + + +CONFIGURATION +============= +To enable this feature, IMMSV_SC_ABSENCE_ALLOWED environment variable +must be set for IMMD (immd.conf) + + export IMMSV_SC_ABSENCE_ALLOWED=900 + +The value indicates the number of seconds cluster will tolerate SC +absence, value of zero indicates the feature is disabled. +See immd.conf for more details. + + +IMMND +===== +With headless feature enabled, IMMNDs on payloads now can be +coordinator. That can happen even when the cluster doesn't go headless. + +For example, the cluster only has one SC and IMMND on SC restarts, one +of the IMMNDs on payloads will be elected as new coordinator. Without +headless enabled, the cluster will not tolerate that situation and a cluster reboot will occur. + +Upon receiving the IMMD down event, payload based IMMNDs unregister +with MDS and then: +- remove all local clients, +- discard all implementers, +- finalize all admin owners, +- abort all non-critical CCBs. + +That means the IMMNDs only keep class definitions and object +information in their memories during headless. + +After cleaning up those things, MDS will be registered again to allow +clients to read the objects but only config data can be read because +there's currently no OI attached for runtime data. + +Other operations with IMM service will get SA_AIS_ERR_TRY_AGAIN during headless. +If you retry the APIs on SA_AIS_ERR_TRY_AGAIN, you should retry at +least the amount of time that you set for IMMSV_SC_ABSENCE_ALLOWED. + +If you get SA_AIS_ERR_BAD_HANDLE, you must re-initialize the handles. + + +IMMD +==== +After coming back from headless, the active IMMD will wait for the +veteran IMMNDs to introduce for 3 seconds. If there's no introduction +from veteran IMMND within 3 seconds, IMMD will start to load from +repository. This is to avoid the race condition where IMMD receives and +processes introduce message from the local IMMND or a newly joined IMMND before the veteran IMMNDs. + +The veteran IMMNDs also include highest fevs, latest id of +implementer/admo/ccb in the introduce message to help IMMD restore +these counters back to the state right before SC absence. + +IMMD then elects one of the veteran IMMNDs as new coordinator and the +data is sync'ed to the SC based IMMNDs. After that, IMM service becomes +fully functional again. + + +HEADLESS and 2PBE +================= +Support for absent IMMD is incompatible with 2PBE. If both are +configured then 2PBE will win and the absence of IMMD feature will be +ignored. An error message is printed in this case to the syslog at startup. + ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev _______________________________________________ Opensaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-devel
