Patrick Caulfield | 1 Nov 2007 09:46
Picon
Favicon

DLM Document

For those wanting more detail on writing applications to use the Red Hat DLM, I
have prepared this document:

 http://people.redhat.com/pcaulfie/docs/rhdlmbook.pdf

It's based quite heavily on the IBM dlmbook document so many thanks to Kristin
Thomas for that work. It's been updated and modified to include things specific
to our DLM including the API reference.

Any comments gratefully received.

Patrick

Stephen Nelson-Smith | 1 Nov 2007 12:03
Picon
Gravatar

High Availability Virtualisation

Hello,

I presently run a bunch of openvz ve's on a fairly beefy machine.

I am somewhat concerned that if this machine fails, the vms fail too.

Other than using redundant hardware (multiple psu, mirrored disks,
etc), how can I increase availability?  I could put the virtual
environments on a shared filesystem, but really I'd like some kind of
failover mechanism.  Is this asking too much?

This looks interesting: http://www.pro-linux.de/work/virtual-ha/virtual-ha5.html

But my German is very rusty, so it's heavy going!

Any ideas?

S.

Re: High Availability Virtualisation


Stephen Nelson-Smith wrote:
> Hello,
> 
> I presently run a bunch of openvz ve's on a fairly beefy machine.
> 
> I am somewhat concerned that if this machine fails, the vms fail too.
> 
> Other than using redundant hardware (multiple psu, mirrored disks,
> etc), how can I increase availability?  I could put the virtual
> environments on a shared filesystem, but really I'd like some kind of
> failover mechanism.  Is this asking too much?
> 
> This looks interesting: http://www.pro-linux.de/work/virtual-ha/virtual-ha5.html
> 
> But my German is very rusty, so it's heavy going!

Google translate helps...

http://translate.google.com/translate?u=http%3A%2F%2Fwww.pro-linux.de%2Fwork%2Fvirtual-ha%2Fvirtual-ha5.html&langpair=de%7Cen&hl=en&ie=UTF8

How I would do it, is with at least one other server.

Partition the machines into multiple xen domains, each xen domain
running something like vserver (supported in debian) or if you prefer it
openvz if you can support it.

With shared storage (where the DRBD comes in (like a network RAID 1))
you can seemlessly migrate xen domains from machine to machine, or
restart them on the other machine in the event of failure.
(Continue reading)

Benjamin Marzinski | 1 Nov 2007 18:49
Picon
Favicon

Re: fence gnbd doesn't works as expected

On Tue, Oct 30, 2007 at 09:00:55AM +0100, carlopmart wrote:
> Hi all,
> 
>  I have already installed two nodes cluster using gnbd as a fence device. 
>  When tow nodes comes up at the same time all works ok, but when only I need 
> to start only one node, GFS doesn't mounts because fence device doesn't 
> works. Error is:
> 
> Mounting GFS filesystems:  /sbin/mount.gfs: lock_dlm_join: gfs_controld 
> join error: -22
> /sbin/mount.gfs: error mounting lockproto lock_dlm.
> 
> I am using a third server as GNBD server wihout serving disks. Why this 
> doesn't works?? Perhaps do I need quorum disk??

Let me see if I understand what you are doing. You want to use
fence_gnbd as your fence device, but the nodes in your cluster aren't
actually using gnbd devices for their shared storage. It this is true,
it won't work at all. All fence_gnbd guarantees is that the fenced node
will not be able to access its gnbd devices. If the GFS filesystems are
on the gnbd devices, this will keep the fenced node from being able to corrupt
them. If a GFS filesystem is not on a GNBD device, fence_gnbd does
nothing at all to protect it from corruption.

You really need quorum disk to deal with this.

-Ben

> My cluster.conf:
> 
(Continue reading)

Paul Risenhoover | 1 Nov 2007 19:03

GFS on raw devices, CLVM and resizing partitions

Hi All,

I am in the process of bringing a new iSCSI device online and redoing 
some of my SAN architecture and I have a few questions that I hope you 
might be able to help with.

The fundamental goal here is to build a two-node active/passive cluster 
to serve as a NAS head with two iSCSI Promise arrays serving as the 
storage devices.  One very desirable requirement is to be able to serve 
up all the disk storage as a single mount point (ie, be able to publish 
a samba share that spans both iSCSI devices).

Now, I've heard that GFS will work on raw partitions and within the CLVM 
context, and I'm tempted to use the raw devices for simplicity, but I'm 
not certain that GFS will allow me to build a partition that spans two 
physical devices.

If anybody could take a moment or two to enlighten me on the benefits of 
raw devices v. clvmd, I'd be most grateful.

Thanks,
Paul

Jos Vos | 1 Nov 2007 19:13
Picon

Re: GFS on raw devices, CLVM and resizing partitions

On Thu, Nov 01, 2007 at 11:03:20AM -0700, Paul Risenhoover wrote:

> Now, I've heard that GFS will work on raw partitions and within the CLVM 
> context, and I'm tempted to use the raw devices for simplicity, but I'm 
> not certain that GFS will allow me to build a partition that spans two 
> physical devices.
> 
> If anybody could take a moment or two to enlighten me on the benefits of 
> raw devices v. clvmd, I'd be most grateful.

A GFS filesystem is always created on one device, just like a "normal" fs,
so if you need to span 2 disks, you need clvmd to create a VG that
includes those two disks.  Then create a LV on that VG on which you put
the GFS fs.

--

-- 
--    Jos Vos <jos <at> xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204

Lon Hohberger | 1 Nov 2007 21:27
Picon
Favicon

Re: High Availability Virtualisation

On Thu, 2007-11-01 at 11:03 +0000, Stephen Nelson-Smith wrote:
> Hello,
> 
> I presently run a bunch of openvz ve's on a fairly beefy machine.
> 
> I am somewhat concerned that if this machine fails, the vms fail too.
> 
> Other than using redundant hardware (multiple psu, mirrored disks,
> etc), how can I increase availability?  I could put the virtual
> environments on a shared filesystem, but really I'd like some kind of
> failover mechanism.  Is this asking too much?

rgmanager can fail over / migrate / restart Xen virtual machines; it
wouldn't be hard to extend it to other libvirt-supported VM systems.

-- Lon

Lon Hohberger | 1 Nov 2007 22:46
Picon
Favicon

Re: clvmd hangs when third node tries to connect to cluster

On Wed, 2007-10-31 at 19:26 +0000, s.c.graham <at> gmail.com wrote:
> >
> > That sounds like a bug that has already been fixed. I don't have the reference
> > to hand as I've just returned from holiday, sorry.
> 
> Does anyone else remember this bug (or could someone please point me
> in the direction of the correct bugzilla so I can try and track it
> down myself)?

338511 might be it, but it could be another one as well.

-- Lon

Manish Kathuria | 2 Nov 2007 13:00
Picon

Re: dlm_sendd and dlm_sendd running on 100% CPU

On 10/29/07, David Teigland <teigland <at> redhat.com> wrote:
> On Mon, Oct 29, 2007 at 12:03:02PM +0800, Huang Xiong wrote:
> > Hi Dave,
> >
> > Have you released this new cluster tarball?
> > If so, can you please tell me where to download and how to use.
>
> https://www.redhat.com/archives/linux-cluster/2007-July/msg00268.html
>
> Dave
>

Any idea if these changes have been incorporated in the RHEL 4 kernels
yet ? A client of mine running Cluster Suite and GFS on RHEL 4 Update
5, further updated till date is facing a similar problem where
dlm_sendd consumes all the CPU time.

Thanks,

Manish

Pedro Espinoza | 2 Nov 2007 17:34
Picon

liblvm2clusterlock.so

Hi

I searched on net, but in vain. This liblvm2clusterlock.so seems to be
missing (as I am trying to install cluster suite with rhel5).

1. May I know which rpm contain this one?
2. Do I need to use locking_type=3?

Here are the details about packages

[root <at> platoc2 scsi]# rpm -qa | grep -i gfs
kmod-gfs-0.1.16-5.2.6.18_8.el5
kmod-gfs-0.1.16-5.2.6.18_8.1.14.el5
gfs-utils-0.1.11-3.el5
gfs2-utils-0.1.25-1.el5

# rpm -qa |grep -i lvm
lvm2-2.02.16-3.el5
lvm2-cluster-2.02.16-3.el5
system-config-lvm-1.0.22-1.0.el5

2.6.18-8.1.14.el5 #1 SMP Tue Sep 25 11:45:55 EDT 2007 x86_64 x86_64
x86_64 GNU/Linux

Thanks, Pedro.


Gmane