On 2008-09-03T19:45:39, Edward Capriolo <[EMAIL PROTECTED]> wrote:
> >>That is so totally not supported ...
> Yes, I knew this was not supported. I was only interested in possible.
Many things are possible, not all of them are good ideas ;-)
> Use Case:
> Company A has:
> 4 Node Linux HA Cluster
> 20 2GB devices of an iscsi SAN
> storagea:disk1,storagea:disk2...storagea:disk20
> 20 IP Addresses 5.5.5.1, 5.5.5.2.....5.5.5.20
> Xen Support
>
> Company A: Wants to start a dynamic web hosting service. You fill out
> the form, you get your web site. This should be carried out
> automatically.
>
> Problem: Where is the data stored before the resources are created in
> the cluster? For example a Pool of unused IP addresses. or a Pool of
> Unused Disk slices. When the first customer signs up:
> A free IP address should be taken from the pool of unused addresses.
> A Free iscsi device should be taken from the pool of unused devices
> A Group Should be created in linux HA
> a resource should be added to the group for the IP
> a resource should be added to the group for the device
Well, if it is indeed "just" 20, I'd put the resources into the CIB
already, and simply not bring them up until needed.
> The goal is to store fixed resources that have not been allocated yet,
> or meta-data about the resource. And the cluster should be self
> reliant, no external resources.
Such data has a tendency to grow.
One day, someone will want billing, someone will additional flags,
account meta-information etc, not all of which can or should be stored
in the CIB (among other things, it is not encrypted).
> I realize this is very outside the goals of linux-ha, but I cant find
> a better place for this data. Lets review some scenarios.
>
> 1) Place the data in a file. Now the entire cluster needs either a
> single point of failure like an NFS server, or we need a clustered
> file system. It does not make sense to store a few chunks of XML. I
> don't like share a key and rsync.
>
> 2) Use a database. Still a single point of failure. There are not many
> multi-master databases. The configuration is not going to scale
> without scripting when new devices are added. Again I just want to
> replicate a few K of XML.
You can, of course, host the meta-data controler as a clustered
resource; for example, a standard fail-over MySQL setup on top of drbd.
Problem solved.
> 4) linux-ha: create my own element
> cons: Break DTD
> cons: Might get banned from linux HA list :)
> Pros: Replicated XML
You will get bit by every update. Your configuration will not be
supportable by us w/o using your special DTD etc. The XML replication is
not very efficient, either, and the CIB tends to be our largest resource
hog already.
You'll certainly not get banned, we all need examples ;-)
> I am looking for a transactional redundant data store for small
> amounts of peristent cluster meta-data that will span out to each node
> on the cluster without manual configuration. I am looking to the
> cib/policy engine because even though it is not a traditional
> database, it *could be used as such.
It probably could. The thing is, every update to the CIB tends to cause
a cluster transition, and even though you can override this, it's
generally not advised.
If conflicts arise, usually one CIB will indeed overwrite the other; and
it might not _always_ be the one you wanted, meaning you lose some of
your state information (which you'd need to fix the CIB).
At the very least, I'd suggest that you go and enhance CIB to support
several database roots - stored in different files too - so that your
proprietary data does not end up in the general CIB used by the PE and
other tools.
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
