>>That is so totally not supported ... Yes, I knew this was not supported. I was only interested in possible.
>>You can store anything in key/value pairs as node attributes. True. I might have objects with three levels of nesting. Flattening out this data to key value pairs is possible but unnatural. It is a trade off XML format down to a byte []. >>You can store it as node attributes. If it is so large and complex that >>that doesn't fit, the CIB is likely the wrong place for it, unless it is >>relevant to the PE. It might be complex, but it will not not be very large. >>No. The DC serializes the updates, and they are incremental. As long as >>the changes don't affect the same object, what you describe won't occur. That is good news. What is meant by 'object' in this case. an XML Element, byte level differential? >>What is the goal, and why? Don't describe the implementation, but the >>use case? (proprietary, but I can relate it to a common situation) 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 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. 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. 3) linux-ha. use node attributes cons: have to use flatten my data into key_value pros: Data is always in sync pros: No extra software 4) linux-ha: create my own element cons: Break DTD cons: Might get banned from linux HA list :) Pros: Replicated XML 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. Thanks for everyones input. _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
