[prev in list] [next in list] [prev in thread] [next in thread]
List: evms-devel
Subject: Re: [Evms-devel] EVMS, ESS and linux-ha
From: Steve Dobbelstein <steved () us ! ibm ! com>
Date: 2003-11-20 16:05:22
[Download RAW message or body]
\
"Thomas Laurids \
Pedersen" To: Steve \
Dobbelstein/Austin/IBM@IBMUS
<tlp@dannet.com> cc: \
evms-devel@lists.sourceforge.net
Subject: Re: [Evms-devel] EVMS, ESS \
and linux-ha
11/20/03 08:39 AM \
\
\
Thomas Laurids Pedersen wrote:
> > I am confused. I assume that the first step is to create a CSM
container.
> > When the CSM container is created, it produces segments that map
one-to-one
> > to the disks in the container. Then you can create a RAID1 region from
the
> > segments produced by the CSM container. (You can't build anything from
a
> > container, since it is just a grouping of devices. Devices are built
from
> > other devices, for example, a RAID1 region built from segments.)
>
> What I can see is that if I have 4 disks, 2 in each ESS and I want to
make
> 2 Raid1 devices accross the 2 ESS systems. I then make 2 private
containers
> with 1 disk in each and add a DOS segment manager to thise 2 containers.
> Then I have 2 private containers with segments (ie pdisk_d/sdb1) and new
2
> disks. Picture attached.
>
> (Embedded image moved to file: pic12859.pcx)
> I then select Create->Region>Raid1 Manager I am presented with available
> storage objects.
>
> If I select on of the 2 remaining disks (sdc or sdg) the container
segmens
> disapear but I can select both the 2 disks for the Raid device. However
if
> I select one of the "private container" segments (sdb1 or sde1) all
other
> disks disapear aincluding the last "private container" segment. I do not
> know if this is a bug and I should have the choise of only selecting
> "private container" segments due to the disks in the mirror must be the
> same but I would expect that I should be able to create Raid1 devide
from
> the 2 "private" segments just as the 2 ordenary disks.
>
> All of this is without adding any EVMS features to the disks.
>
Thanks for the description and the picture. I now understand your
configuration and what is happening.
This is "working as designed". :) EVMS now enforces the rule that object
can only be created from objects that are in the same disk group (CSM
container). Without this rule, you could create an object, say, a RAID1
mirror, from objects in two disk groups, say, one disk on the local machine
and one disk in a private disk group called "nodeA" on shared storage. You
could then later assign the disk group to another node on the cluster, as
you would in a failover scenario. For example, node A dies, and the disk
group is assigned to "nodeB". Node B in the cluster would see the one disk
in the private disk group, but it could not see the one disk that is local
to node A. Since disk groups can be reassigned to different nodes and even
converted from shared to private and vice versa, objects cannot be allowed
to span disk groups since a change of ownership of one of the disk groups
would break the building of the object.
When a plug-in presents its first panel of selectable objects, it displays
all the available objects in all the disk groups because it initially does
not know in which disk group the object will be created. Once you select
an object, the plug-in then knows which in disk group the new object will
be created and removes from the list of selectable objects all the objects
that are not in the same disk group as the selected object.
In your case you have three disk groups--the "local" disk group (a virtual
disk group for all disks that are not part of a CSM container), disk group
"pdisk_d", and disk group "pdisk_e". I assume that disks sdc and sdg are
on shared storage and can be seen by all the nodes in the cluster. Without
the Cluster Segment Manager being installed on the shared disks, EVMS
cannot tell the difference between disks that are local to the machine and
those that are on shared storage. They all appear as plain disks. There
is nothing EVMS can query to tell the difference. So, in your case EVMS
assumes that disks sdc and sdg are local to the machine and therefore part
of the "local" disk group.
When you are building your RAID1 array, your initial available selections
are all the available objects,: sdc, sdg, pdisk_d/sdb1, pdisk_e/sde1,
sda4, and md/md0. If you first select sdc, sdg, sda4, or md/md0 (any
object in the "local" disk group), then the objects in the private disk
groups (pdisk_d/sdb1 and pdisk_e/sde1) will be removed from the list. If
you first select pdisk_d/sdb1, then all objects not in disk group pdisk_d
(all the remaining objects) will be removed from the list. Similarly, if
you first select pdisk_e/sde1, then all the objects not in disk group
pdisk_e (all the remaining objects) will be removed from the list. This
describes what you are seeing.
If you plan to use disks sdb and sde to create a mirror, then I recommend
that you create one disk group that contains both disks. In general, any
disks on shared storage that you plan to use together to create objects
should be put in the same disk group. That way when the disk group
ownership changes all of the objects and volumes in the disk group will be
migrated to the new owner.
> Thanks for your time !
Always glad to help. :)
Steve D.
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Evms-devel mailing list
Evms-devel@lists.sourceforge.net
To subscribe/unsubscribe, please visit:
https://lists.sourceforge.net/lists/listinfo/evms-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic