SUMMARY: disksuite: where to put meta databases?

Hello!

I had to keep my promise to summarize this issue, even if it is a long time
ago...



> Where should the replicas for the state database ideally be put?
> Should the slice be put in the beginning, the middle or the end of a disk?
(for performance reasons and/or stabililty)

The metadbs aren't acessed alot, typically only when the machine
starts up and when changes are made, ie. disk failed, disk removed etc.

I don't believe that location on disk is an issue; the replicas are small and
as far as I know, they aren't accessed very often (read at boot and written
during changes which are infrequent).

replicas are small, and are only accessed during state changes or when
bringing things online. There should be no real performance problems
wherever you put it.

> Should all disks contain a slice for the state database?

Can, but in big systems, it can be an overhead..

Up to you. If you have 2 disks, yes. If you 100 disks, maybe not.

You'll want enough that you could lose some disks (or maybe a
controller) and keep at least 50%. With 3 controllers and lots of
disks, this is easy. With one controller and few disks, it's more
difficult. :-)

> How many replicas could be used without causing performance problems for
DiskSuite?

don't know, but I typically not going over a screen full of metadb output,
as I then have to scroll back :)

I'm not aware of any performance problems with disksuite having "too many"
replicas.

AFAIK, the main criteria with MetaDB is to have as much redundancy as
possible, but beyond that, I don't think there are significant "performance
issues" about where the things actually live.

I've never used DS with more than about 20 disks. Each contained a
replica and I didn't notice trouble.

Remember, the info in these db's basically never changes, so it's not like you
gather up a lot of overhead by having a few extra metadbs lying around.

> Should I dedicate a disk just to contain state database replicas for some
reason?

No, definately NOT.
1) wasting space,
2) no redundancy :(

You should not dedicate a disk to replicas; as well as creating a single point
of failure (lose the disk, lose the system), it's a waste of space. You can
easily fit 3 replicas in a 10MB partition.

No... what happens if you lose that disk?

That would be a bad idea. Loss of this single disk will cause pain.




> And finally some additional info from several guys:

You should try to balance the replicas across disks and controllers, but try
to imagine what would happen if a controller dies; i.e. if you have two
internal disks and 6 internal disks, don't put a replica on each disk as the
loss of the external disks would result in a loss of quorum.

Can't tell you about location on each disk. For the rest of your questions, it
would help to know how many disks you are going to use disksuite for. When I
have two disks I put three replicas on each, so that if one dies I still have
a quorum. You should put at least one replica on each disk for performance.
With three disks you might be able to get by using one or two per, but why not
use three?

The adviced way is to spread them over as many controllers as possible, after
that over as many disks as posible.
I typically "stage" all the disks in bigger setups with a 1 cylinder at
the start to prevent DBs etc. corupting the VTOC/partition table, and that's
where I put my metadbs.
If I have a few disks, I add more than one metadb per disk, and make sure
I have an odd amount of metadbs.


if you have 2 controllers and 8 drives total in a system, [drives 1-4 on C1,
drives 5-8 on C2] ensure to have at least one copy of metadb on devices under
each seperate controller, and likely prudent to have a few more copies than
that - say, a total of 4 metadb replicas, 2 per controller, one per drive, on
drives 1,3 and 6,8.

I dont know about best practise. My practise is
A small slice (minimal number of cynders) on each disk with each disk
containing at two copies of the data base in this slice. If there were many
disks involved, perhaps only one copy on each disk would be required.

A brief explanation about metadbs. You can place them into a small unused
partition, at the beginnig of any used partition ( if u have enough space,
of course), and even you can "steal" some space from swap; this is, you can
boot in single user mode, delete the swap partition using the command "swap
-d", repartition the disk using your new free space and construct the
partition you need, and finally boot the system and add swap space.
At least three copies of the metadb are needed. The explanation for this is
a little larger; I recommend you to read DiskSuite 4.2.1 administration
guide. This is available at docs.sun.com in pdf format.
Sorry for may grammar mistakes, I'm not very good at English.




many thanks to:

Hendrik Visage [hvisage@is.co.za]
Riddoch, John E SITI-ITDSEP3 [John.E.Riddoch@is.shell.com]
Eva Harlington [anaestuardo@hotmail.com]
Tim Chipman [chipman@ecopiabio.com]
Mike's List [mikelist@sky.net]
Darren Dunham [ddunham@taos.com]
Broun, Bevan [brounb@adi-limited.com]
eshafto@mac.com


/jonas


-----Ursprungligt meddelande-----
Fren: Jonas Bleberg
Skickat: den 16 april 2002 10:33
Till: sunmanagers@sunmanagers.org
Dmne: disksuite: where to put meta databases?


hello!
some questions about disksuite and how to organize things according to
security and performance.
Where should the replicas for the state database ideally be put?
Should the slice be put in the beginning, the middle or the end of a disk?
(for performance reasons and/or stabililty)
Should all disks contain a slice for the state database?
How many replicas could be used without causing performance problems for
DiskSuite?
Should I dedicate a disk just to contain state database replicas for some
reason?
etc.
Someone, somewhere has probably asked those questions before...
I will summarize. /jonas


Jonas Bleberg
  Cell Network Sverige AB
  Kruthusgatan 17,6
  S-411 04 Gvteborg
jonas.blaberg@cellnetwork.com
@office: +46-(0)31-707 69 85
not@office: +46-(0)709-95 00 68
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers