--- On Fri, 10/3/08, Doug Tucker <tuckerd@xxxxxxxxxxxx> wrote: > From: Doug Tucker <tuckerd@xxxxxxxxxxxx> > Subject: Re: rhcs + gfs performance issues > To: "linux clustering" <linux-cluster@xxxxxxxxxx> > Received: Friday, October 3, 2008, 3:47 PM > Let me say first, I appreciate your help tremendously. Let > me answer > some questions, and then I need to go do some homework you > have > suggested. > > > > In your cluster.conf, make sure in the > > > > <cluternode name="node1c".... > > > > section is pointing at a private crossover IP of the > node. Say you have > > 2nd dedicated Gb interface for the clustering, assign > it address, say > > 10.0.0.1, and in the hosts file, have something like > > > > 10.0.0.1 node1c > > 10.0.0.2 node2c > > > > That way each node in the cluster is referred to by > it's cluster > > interface name, and thus the cluster communication > will go over that > > dedicated interface. > > > I'm not sure I understand this correctly, please bear > with me, are you > saying the communication runs over the fenced interface? > Or that the > node name should reference a seperate nic that is private, > and the > exported virtual ip to the clients is done over the public > interface? > I'm confused, I thought that definition had to be the > same as the > hostname of the box? Here is what is in my conf file for > reference: > > <clusternode name="engrfs1.seas.smu.edu" > nodeid="1" votes="1"> > <fence> > <method > name="1"> > <device > modulename="" > name="engrfs1drac"/> > </method> > </fence> > </clusternode> > <clusternode > name="engrfs2.seas.smu.edu" nodeid="2" > votes="1"> > <fence> > <method > name="1"> > <device > modulename="" > name="engrfs2drac"/> > </method> > </fence> > > Where as engrfs1 and 2 are the actual hostnames of the > boxes. the cluster will do the hearbeat and internal communication through the interface that the "nodes" (declared in cluster.conf) are reachable that mean that you can use "internal" names (name declared in /etc/hosts in every node) just for the cluster communication > > > > I see, so you had two servers in a load-sharing > write-write > > configuration before, too? > Certainly were capable of such. However here, as we did > there, we set > it up in more of a failover mode. We export a virtual ip > attached to > the nfs export, and all clients mount the vip, so whichever > machine has > the vip at a given time is "master" and gets all > the traffic. The only > exception to this is the backups that run at night, we do > on the > "secondary" machine directly, rather than using > the vip. And the > secondary is only there in the event of a failure to node1, > when node1 > comes back online, it is set up to fail back to node1. > > > > > > If you set the nodes up in a fail-over configuration, > and server all the > > traffic from the primary node, you may see the > performance improve due > > to locks not being bounced around all the time, > they'll get set on the > > master node and stay there until the master node fails > and it's floating > > IP gets migrated to the other node. > As explained above, exactly how it is set up. Old file > server the same then I suggest you to define the service as failover (active-pasive) but the fs as GFS so you can mount it on-demand when you need to made the backup then umount it that way during normal workload the cluster nodes will not need to agree when reading/writing to the FS and, also you should measure the performance of the NFS standalone linux server compared to the tru64 nfs server, maybe the big performance degradation you are noticing is not the cluster layer thanks roger -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
