18.5 Cluster Mount Services (CMS)


18.5 Cluster Mount Services (CMS)

By now you're probably aware that there are many behind-the-scenes components of a cluster all struggling to make the entire operation of a very complex environment as transparent as possible. One component that quietly does its job is the Cluster Mount Services (CMS). Somehow, magically, when you mount a file system on one member of the cluster, all the other members can see the mount point. Not that we're trying to turn this into an internals discussion, but every mounted file system is supported by a mount structure in the kernel. No big deal, right? Consider the fact that this activity was instigated on one cluster member but ended up writing into kernel address space on all cluster members! A very impressive deed requiring synchronization among all cluster members (and yes, it does involve DLM to achieve some of the synchronization – but you were already thinking that weren't you?).

The following output displays CMS subsystem attributes that limit the number of cluster-wide mounts available per file system type.

 # sysconfig -q cms cms: cmsdbg_flags = 0 cfs_advfs_mount_limit = 4096 cfs_cdfs_mount_limit = 512 cfs_dvdfs_mount_limit = 512 cfs_nfs_mount_limit = 8192 cfs_ufs_mount_limit = 512 cfs_mfs_mount_limit = 512 

 # sysconfig -Q cms cms: cmsdbg_flags - type=ULONG         op=CRQ    min_val=0    max_val=18446744073709551615 cfs_advfs_mount_limit - type=INT  op=CRQ    min_val=0    max_val=2147483647 cfs_cdfs_mount_limit - type=INT   op=CRQ    min_val=0    max_val=2147483647 cfs_dvdfs_mount_limit - type=INT  op=CRQ    min_val=0    max_val=2147483647 cfs_nfs_mount_limit - type=INT    op=CRQ    min_val=0    max_val=2147483647 cfs_ufs_mount_limit - type=INT    op=CRQ    min_val=0    max_val=2147483647 cfs_mfs_mount_limit - type=INT    op=CRQ    min_val=0    max_val=2147483647 

The mount activity starts with a local mount command that involves CFS and is ultimately propagated to other cluster members through RPCs. The CMS activity heavily involves KGS (section 18.4). In fact, we can say that CMS is a client of KGS. CMS receives mount proposals (and membership change information) from KGS. The mounting member may be told (through KGS) that the file system has already been mounted by another member. In that case, CMS simply "joins" the KGS set. If it has not been mounted by another member, the member proposes that other members "join" the new KGS set representing the file system.

KGS is at the heart of CMS and uses DLM for synchronization.




TruCluster Server Handbook
TruCluster Server Handbook (HP Technologies)
ISBN: 1555582591
EAN: 2147483647
Year: 2005
Pages: 273

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net