Showing posts with label GPFS. Show all posts
Showing posts with label GPFS. Show all posts

Friday, May 27, 2016

GPFS Nodes being Expelled by Failed GPFS Clients

According to IBm Developer Wiki Troubleshooting Debug Expel  
  • Disk Lease Expiration - GPFS uses a mechanism referred to as a disk lease to prevent file system data corruption by a failing node. A disk lease grants a node the right to submit IO to a file system. File system disk leases are managed by the Cluster Manager of the file system's home cluster. A node must periodically renew it's disk lease with the Cluster Manager to maintain it's right to submit IO to the file system. When a node fails to renew a disk lease with the Cluster Manager, the Cluster Manager marks the node as failed, revokes the node's right to submit IO to the file system, expels the node from the cluster, and initiates recovery processing for the failed node.
  • Node Expel Request - GPFS uses a mechanism referred to as a node expel request to prevent file system resource deadlocks. Nodes in the cluster require reliable communication amongst themselves to coordinate sharing of file system resources. If a node fails while owning a file system resource, a deadlock may ensue. If a node in the cluster detects that another node owing a shared file system resource may have failed, the node will send a message to the file system Cluster Manger requesting the failed node to be expelled from the cluster to prevent a shared file system resource deadlock. When the Cluster Manager receives a node expel request, it determines which of the two nodes should be expelled from the cluster and takes similar action as described for the Disk Lease expiration.
But in my case, I have an errant failed GPFS Client node in the network which was within the cluster. All the other legitimiate GPFS Client was trying to expel this failed node, but got expel instead. The errant one remain, while the legitimate was expelled. The only solution was to power off this errant and the entire GPFS File System became operational. Here is an except in the Log File of the NSD Nodes. in fact, a lots of hints are found on the /var/adm/ras/mmfs.log.latest of any NSD Nodes. You should be able to locate it there.
  
Fri May 27 16:34:53.249 2016: Expel 172.16.20.5 (goldsvr1) request from 192.168.104.34 (compute186). Expelling: 192.168.104.34 (compute186)
Fri May 27 16:34:53.259 2016: Recovering nodes: 192.168.104.34
Fri May 27 16:34:53.311 2016: Recovered 1 nodes for file system gpfs3.
Fri May 27 16:34:55.636 2016: Accepted and connected to 10.0.104.34 compute186 <c0n135>
Fri May 27 16:39:13.333 2016: Expel 172.16.20.5 (goldsvr1) request from 192.168.104.45 (compute197). Expelling: 192.168.104.45 (compute197)
Fri May 27 16:39:13.334 2016: VERBS RDMA closed connection to 192.168.104.45 compute197 on mlx4_0 port 1
Fri May 27 16:39:13.344 2016: Recovering nodes: 192.168.104.45
Fri May 27 16:39:13.393 2016: Recovered 1 nodes for file system gpfs3.
Fri May 27 16:39:15.725 2016: Accepted and connected to 10.0.104.45 compute197 <c0n141>
Fri May 27 16:40:18.570 2016: VERBS RDMA accepted and connected to 192.168.104.45 on mlx4_0 port 1

Thursday, July 23, 2015

GPFS Client Node cannot be added to the GPFS cluster

At the NSD Node, I issue the command
# mmaddnode -N node1
Thu Jul 23 13:40:12 SGT 2015: mmaddnode: Processing node node1
mmaddnode: Node node1 was not added to the cluster.
The node appears to already belong to a GPFS cluster.
mmaddnode: mmaddnode quitting.  None of the specified nodes are valid.
mmaddnode: Command failed.  Examine previous error messages to determine cause.
If we do a mmcluster, the node is not around in the cluster
# mmcluster |grep node1
If the node is not in the cluster, issue this command on the client node that could not be added:
# mmdelnode -f
mmdelnode: All GPFS configuration files on node goldsvr1 have been removed.
Reissue the mmaddnode command. References:
  1. Node cannot be added to the GPFS cluster

Wednesday, August 27, 2014

Location of GPFS Client Log file

The location of the GPFS Log file is located at the /var/adm/ras/mmfs.log.latest. You can find a wealth of information of errors and information. When you are monitoring the errors in real time, you may want to use the tail -f to see the real time troubleshooting

# tail -f /var/adm/ras/mmfs.log.latest

Sunday, August 24, 2014

GPFS Autoconfig Error on CentOS 6

When I try to build the portability layer for GPFS which is done by

make LINUX_DISTRIBUTION=REDHAT_AS_LINUX Autoconfig
 There are errors like the ones below
cd /usr/lpp/mmfs/src/config; ./configure --genenvonly; /usr/bin/cpp -P def.mk.proto > ./def.mk; exit $? || exit 1
Cannot find a valid kernel include dir
def.mk.proto:12:19: error: env.mcr: No such file or directory
make: *** Autoconfig Error 1

The solution is to make sure you have all the package installed. These are the following prerequistics

kernel-headers-2.6.18-128.el5.x86_64.rpm
kernel-devel-2.6.18-128.el5.x86_64.rpm
libgomp-4.3.2-7.el5.x86_64.rpm
glibc-headers-2.5-34.x86_64.rpm
glibc-devel-2.5-34.x86_64.rpm
gcc-4.1.2-44.el5.x86_64.rpm
libstdc++-devel-4.1.2-44.el5.x86_64.rpm
gcc-c++-4.1.2-44.el5.x86_64.rpm

References:
  1. Linux system does not have prerequisite kernel or C++ packages 

Tuesday, July 15, 2014

mmgetstate -a lists all nodes in unknown state

After I setup the GPFS NSD Nodes, I did a "mmgetstate -a", I noticed that my NSD Nodes shows all the compute nodes in an unknown state.

# mmgetstate -a 
.....
.....
node1    unknown
node2    unknown 
node3    unknown
.....
.....

There are a lot of reasons why "mmgetstate -a" produce the unknown state. For my case, it was a simple resolution, it was just that my /etc/hosts file was not updated. After I updated the /etc/hosts file for all the NSD Node, my solution was fixed.


Monday, December 16, 2013

GPFS NSD Nodes stuck in Arbitrating Mode

One of our GPFS NSD Nodes are forever stuck in arbitrating nodes. One of the symptoms that was noticeable was that the users was able to log-in but unable to do a "ls" of their own directories. You can get a quick deduction by looking at one of the NSD Nodes. For this kind of issues, do a mmdiag --waiters first. There are limited articles on this
# mmdiag --waiters 

.....
.....
0x7FB0C0013D10 waiting 27176.264845756 seconds, SharedHashTabFetchHandlerThread: 
on ThCond 0x1C0000F9B78 (0x1C0000F9B78) (TokenCondvar), reason 'wait for SubToken to become stable'
References:
  1. IZ17622: GPFS DEADLOCK WAITING FOR SUBTOKEN TO BECOME STABLE CAUSES HANG
  2. GPFS File System Deadlock

For more information on the resolution, see  GPFS NSD Nodes stuck in Arbitrating Mode (Linux Cluster)

Thursday, November 7, 2013

Resolving mmremote: Unknown GPFS execution environment when issuing mmdelnode commands

I was issuing a mmdelnode from the NSD node to a client node which are having issues, but somehow I keep getting this error.

[root@nsd1]# mmdelnode -N node-c01

Verifying GPFS is stopped on all affected nodes ...
node-c01-nas:  mmremote: Unknown GPFS execution environment
mmdelnode: Command failed.  Examine previous error messages to determine cause.

If you do a mmgetstate -a on the NSD node, you will get something like this
# mmgetstate -a 
.....
.....
05      node-c01   unknown
.....
.....

The resolution is not too difficult. According to IBM GPFS Administration and Programming References mmdelnode

You have to power down the affected node and do the mmdelnode again. You can see it is successful.
# mmdelnode -N node-c01

Verifying GPFS is stopped on all affected nodes ...
mmdelnode: Command successfully completed
mmdelnode: Propagating the cluster configuration data to all
affected nodes.  This is an asynchronous process.

Do a mmgetstate -a and you will see that the node deletion is successful

Saturday, November 2, 2013

GPFS Error: Unable to delete Client Node from GPFS Cluster

Today when we were delete a Client GPFS Node, the error received was something like:

 Fri Nov  1 11:55:03 SGT 2013: mmaddnode: Processing node node01
mmaddnode: Node node01 was not added to the cluster.
   The node appears to already belong to a GPFS cluster.
mmaddnode: mmaddnode quitting.  None of the specified nodes are valid.

When we do the command mmlcluster, the node was not in the list. So in other words, we are not able to add or delete the node.

Solution: Just reinstall. But you may have to remove old information
# rm -fr /usr/lpp
# rm -fr /var/mmfs

Reinstall and add the GPFS Node again. For more information, do take a look at  Adding nodes to a GPFS cluster


Monday, May 6, 2013

Enable and Disable Quota Management for GPFS

Taken from GPFS Administration and Programming Reference – Enabling and disabling GPFS quota management
To enable GPFS quota management on an existing GPFS file system
  1. Unmount the file system everywhere.
  2. Run the mmchfs -Q yes command. This command automatically activates quota enforcement whenever the file system is mounted.
  3. Remount the file system, activating the new quota files. All subsequent mounts follow the new quota setting.
  4. Compile inode and disk block statistics using the mmcheckquota command. The values obtained can be used to establish realistic quota values when issuing the mmedquota command.
  5. Issue the mmedquota command to explicitly set quota values for users, groups, or filesets.
Once GPFS quota management has been enabled, you may establish quota values by:
  1. Setting default quotas for all new users, groups of users, or filesets.
  2. Explicitly establishing or changing quotas for users, groups of users, or filesets.
  3. Using the gpfs_quotactl() subroutine.
To disable quota management:
  1. Unmount the file system everywhere.
  2. Run the mmchfs -Q no command.
  3. Remount the file system, deactivating the quota files. All subsequent mounts obey the new quota setting.
To enable GPFS quota management on a new GPFS file system:
  1. Run  mmcrfs -Q yes command. This option automatically activates quota enforcement whenever the file system is mounted.
  2. Mount the file system.
  3. Issue the mmedquota command to explicitly set quota values for users, groups, or filesets. See Explicitly establishing and changing quotas.

Thursday, May 2, 2013

Deleting Nodes from a GPFS Cluster

Taken from Deleting Nodes from a GPFS Cluster (IBM)

Step 1: Shutdown the Nodes before deleting
On the NSD Node
# mmshutdown -N node01

mmshutdown -N node01 
Wed May  1 01:09:51 SGT 2013: mmshutdown: Starting force unmount of GPFS file systems
Wed May  1 01:09:56 SGT 2013: mmshutdown: Shutting down GPFS daemons
node01:  Shutting down!
node01:  'shutdown' command about to kill process 10682
node01:  Unloading modules from /lib/modules/2.6.32-220.el6.x86_64/extra
node01:  Unloading module mmfs26
node01:  Unloading module mmfslinux
node01:  Unloading module tracedev
Wed May  1 01:10:04 SGT 2013: mmshutdown: Finished


Step 2: Deleting a Node
# mmdelnode -N node01

Verifying GPFS is stopped on all affected nodes ...
mmdelnode: Command successfully completed
mmdelnode: Propagating the cluster configuration data to all
affected nodes.  This is an asynchronous process.


Step 3: Confirm that the nodes has been deleted
# mmlscluster


Step 4: If you are deleting the client permanently, check and update the license file.
# mmlslicense

Summary information
---------------------
Number of nodes defined in the cluster:                         20
Number of nodes with server license designation:                 3
Number of nodes with client license designation:                17
Number of nodes still requiring server license designation:      0
Number of nodes still requiring client license designation:      0

Wednesday, September 26, 2012

Total Reconfiguration of GPFS from scratch again

If you have messed things up in the configuration and wish to redo the entire setup again, you have to do the following. From our training at GPFS, there are 2 advisable ways. The first one is the recommended way. The latter one is the “nuclear” option.

For more information, see  Total Reconfiguration of GPFS from scratch again

Friday, August 24, 2012

Installing GPFS 3.4 Packages on a Linux Client


In this work-in-progress tutorial, I will write how to install the General Parallel File System (GPFS) packages and compile portability layer (gpfs.gplbin) for each kernel or  architecture. For more information, see Installing GPFS 3.4 Packages on a Client

Do read Adding nodes to a GPFS cluster

Monday, August 20, 2012

Adding Nodes to a GPFS Cluster


I fumbling how to setup a GPFS Cluster and has written a simple tutorial from my experimentation. See Adding Nodes to a GPFS Cluster.

Friday, August 17, 2012

runmmfs: Unable to verify kernel/module configuration.

Taken from GPFS Determination Guide

If you are running General Parallel File System, you may encounter the error found at/var/adm/ras/mmfs.log.latest

 This problems occurs if:
  1. The portability layer is not built.
  2. The GPFS kernel modules, mmfslinux and tracedev, are built with a kernel version that differs from that of the currently running Linux kernel. This situation can occur if the modules are built on another node with a different kernel version and copied to this node, or if the node is rebooted using a kernel with a different version.

Mon Mar 26 20:56:30 EDT 2012: runmmfs starting
Removing old /var/adm/ras/mmfs.log.* files:
Unloading modules from /lib/modules/2.6.32.12-0.6-ppc64/extra
runmmfs: The /lib/modules/2.6.32.12-0.6-ppc64/extra/mmfslinux.ko kernel extension does not exist.
runmmfs: Unable to verify kernel/module configuration.
Loading modules from /lib/modules/2.6.32.12-0.6-ppc64/extra
runmmfs: The /lib/modules/2.6.32.12-0.6-ppc64/extra/mmfslinux.ko kernel extension does not exist.
runmmfs: Unable to verify kernel/module configuration.
Mon Mar 26 20:56:30 EDT 2012 runmmfs: error in loading or unloading the mmfs kernel extension
Mon Mar 26 20:56:30 EDT 2012 runmmfs: stopping GPFS

Wednesday, December 1, 2010

IBM Redbook - Configuration and Tuning GPFS for Digital Media Environments

An Interesing Red-Book named "Configuration and Tuning GPFS for Digital Media Environments "especially if you , abeit a long thick e-book with 272 pages.

Happy Reading!

Thursday, April 22, 2010

GPFS Tuning Parameters

GPFS Tuning Parameters is a good wiki information resource written by IBM for GPFS Tuning. Just parroting some of the useful tips I have learned

To view the configuration parameters that has been changed from the default
mmlsconfig

To view the active value of any of these parameters you can run
mmfsadm dump config

To change any of these parameters use mmchconfig. For example to change the pagepool setting on all nodes.
mmchconfig pagepool=256M


1. Consideration to modify the PagePool

A. Sequential I/O
The default pagepool size may be sufficient for sequential IO workloads, however, a recommended value of 256MB is known to work well in many cases. To change the pagepool size
mmchconfig pagepool=256M [-i]

If the file system blocksize is larger than the default (256K), the pagepool size should be scaled accordingly. For example, if 1M blocksize is used, the default 64M pagepool should be increased by 4 times to 256M. This allows the same number of buffers to be cached.


B. Random I/O
The default pagepool size will likely not be sufficient for Random IO or workloads involving a large number of small files. In some cases allocating 4GB, 8GB or more memory can improve workload performance.
mmchconfig pagepool=4000M


C. Random Direct IO
For database applications that use Direct IO, the pagepool is not used for any user data. It's main purpose in this case is for system metadata and caching the indirect blocks of the database files.



D. NSD Server
Assuming no applications or Filesystem Manager services are running on the NSD servers, the pagepool is only used transiently by the NSD worker threads to gather data from client nodes and write the data to disk. The NSD server does not cache any of the data. Each NSD worker just needs one pagepool buffer per operation, and the buffer can be potentially as large as the largest filesystem blocksize that the disks belong to. With the default NSD configuration, there will be 3 NSD worker threads per LUN (nsdThreadsPerDisk) that the node services. So the amount of memory needed in the pagepool will be 3*#LUNS*maxBlockSize. The target amount of space in the pagepool for NSD workers is controlled by nsdBufSpace which defaults to 30%. So the pagepool should be large enough so that 30% of it has enough buffers.




For more information
  1. GPFS Tuning Parameters
  2. mmchconfig Command