18.4 Kernel Group Services (KGS a.k.a. KCH)

18.4 Kernel Group Services (KGS a.k.a. KCH)

Kernel Group Services, as described in the chapter introduction, provides for "car pool membership and decisions during cluster communication." A cluster, by its nature, can change dynamically. Members can be added and removed, applications can come and go, services can change, and so forth. If one person in the car pool wants to go to the local donut shop, do we just drop him off, or do we all go? In order to keep track of all these comings and goings, and to provide a mechanism to moderate decisions during changes, KGS is in place.

Rumor has it that as this software was being developed, it had a name that indicates the difficulty of its control and moderator duties. They called it the Kernel Cat Herder (KCH). As you can see in the following sample outputs, the old acronym still has validity. So you will notice references to KGS and KCH. Both terms refer to the same functionality. Figure 18-6 shows the position of KGS in the component hierarchy.

Figure 18-6: KGS Cluster Subsystem Communication

The basic idea was to hide the details of the dynamic activities happening within the cluster from the clients. KGS is used by the CFS, CLUA, CMS, and DRD and may be used by other components. In order to be informed of cluster events pertaining to a particular service, the services would ask KGS to allow them to join a "set". (This set is like a herd of cats. Imagine how difficult it would be to get a bunch of cats to move in the same direction. If you've ever spent time with cats, you know what it means.) If a set member (the initiator) senses a change about which the other members should be informed, it sends this information to KGS in the form of a "proposal" (i.e., "I feel the need for a donut" – Figure 18-7).

Figure 18-7: KGS – "I feel the need for a donut."

Other members of the set are notified by KGS of the proposed change ("Let's all go to the Donut Shop" – Figure 18-8).

Figure 18-8: KGS – "Let's all go to the Donut Shop."

The members "vote" on whether to "accept" the proposal ("How many of you want to go?" – Figure 18-9).

Figure 18-9: KGS – "How many of you want to go?"

If any member "rejects" the proposal, it is not "committed" (the change is not recognized – somebody in the car pool needed to get to work or is on a diet). Otherwise, the change is committed ("We're going for donuts" – Figure 18-10).

Figure 18-10: KGS – "We're going for donuts."

KGS is the moderator during the decision making process. An example would be as follows: if a system tries to run a software product that is potentially incompatible with software running in an existing cluster, the system trying to "join" in the existing software set could report to KGS concerning the version of the software that it is running. If it is not compatible with the software running on current members of the cluster, there will be a "rejection," and the requesting member's software activities could be excluded from the cluster or otherwise disallowed from running the incompatible software. This unfortunate event would be reported to the applicant by KGS. This example would require that the software be built using the KGS mechanisms (usually reserved for kernel components). Another example of the use of KGS is presented in section 18.5 (Cluster Mount Services).

There is no reference page to support the sub-system attributes shown in the output below. We are presenting our best estimation of the meaning of the attributes. Before examining them, here are some additional terms and concepts.

The first member to initiate a "set" will be the "synchronizer" member (think of the director in the lock manager – it uses a similar strategy). Other references to the set are resolved by hashing the set name into a number, using the number as an offset into a directory weight table containing cluster system IDs (csids). The csid found at the calculated offset in the hash table will be the ID of the director to the synchronizer member for that set. Note that the director member may also be the synchronizer. The director member (found through the directory weight table) checks its "set" information to see if it knows which member is the "synchronizer" for the requested set. The "director" responds to the "initiator" and indicates who the "synchronizer" member is. Subsequent requests for that set are sent directly to the synchronizer. The idea is to distribute the KGS activities over the members of the cluster. If you have a member of the cluster with much more capacity than the others, you may improve its odds of being chosen as a "synchronizer" by increasing the kch_dirwt attribute below (maximum value is 4). Note that as of this writing, the kch_dirwt value is fixed at 1.

Caution

These attributes should not be altered unless directed to do so by HP engineering.

 # sysconfig -q kch kch: kch_enabled = 1                          ←Service enabled (1=yes) kch_sets_allocated = 25                  ←Existing set count kch_mbrs_allocated = 25                  ←Members are active set participants kch_lstnrs_allocated = 0                 ←Listeners are nonvoting members of a set kch_dirwt = 1                            ←Directory table weight factor kch_set_tbl_hash_size = 8192             ←Hash table size 

 # sysconfig -Q kch kch: kch_enabled           - type=INT    op=CQ    min_val=0    max_val=1 kch_sets_allocated    - type=UINT   op=Q     min_val=0    max_val=4294967295 kch_mbrs_allocated    - type=UINT   op=Q     min_val=0    max_val=4294967295 kch_lstnrs_allocated  - type=UINT   op=Q     min_val=0    max_val=4294967295 kch_dirwt             - type=INT    op=Q     min_val=0    max_val=4 kch_set_tbl_hash_size - type=UINT   op=CQ    min_val=8192 max_val=32768