On Wed, 2002-09-11 at 16:46, sean.upton@uniontrib.com wrote:
I strongly considered this option at one time with a shared DAS/RAID between my primary and secondary ZSS. I never ended up doing this because of concerns.
Out of curiosity, with shared storage over SCSI/SAN, do you have any thoughts on how to overcome the following issues?
1 - Data fencing (using SAN switches+integrated software, or STONITH devices, or something)??
I've found the best means for doing this in a failover situation is an FC switch with remote management through, say telnet. I've developed a python set of tools for controlling, for example, a Brocade FC switch through telnet. STONITH can be implemented through zoning control. For example, you set up two zones, one per server in this case, and when you need to "shoot" one, you disable the appropriate zone.
2 - Clean up a broken FileStorage? To what degree can this be successfully automated without manual intervention of a sysadmin?
In the configuration I describe, the same as a standard FileStorage. That is one of the gems of the system, all standard tools work like normal.
3 - Deal with accidental damage to the storage done by the primary node, perhaps due to asynchronous writes to the file?
I don't think I quite understand you here. The system I described provides fail over capabilities, so when the backup node comes online (it could be a hot standby) it opens data.fs just as it would normally. In the system I describe (and implemented), we are talking about a stock ZEO/ZODB/ZOPE setup, so I don't see this as a likelihood. Shared storage, but only one ZSS has write-capabilities.
It really seems like replication is really a less brittle option (though how much less brittle, I'm not sure).
It depends on what you are after. In my cases, there is a redundant ZSS, or multiple read-only ZSSes, all "sharing" the same data.fs. Sure, if your write-ZSS goes haywire and hoses the database, you are restoring from backup, or recovering some other way. Replication will suffer the same possibility, unless it provides some sort of check against a haywire write-process. Replicating a bad data.fs doesn't seem to be much help. :) Replication is one method, and has it's drawbacks (like synchronization). Shared storage with fail over is another. If you don't like SAN using FC, use a NAS box, with a physically separate network for mounting the NAS, and implement it that way. Granted, that has it's issues too, but then again so do all the options. :^) It all depends on your requirements and needs, as well as resources and experience. Myself, I have extensive experience in heavy-duty SAN workings, so I am most comfortable with a shared storage system. For "high-end" it is a very powerful option, and can be done at the midrange, etc.. This is where, as a consultant, the cost of ZEO/ZODB/ZOPE can become a powerful tool. If a client has a budget, of say 50 grand for hardware/software, expecting the software to be half that cost, for example, you can improve the hardware --improving reliability and scalability-- and possibly save money for them at the same time. Sometimes they are not too interested in saving money, but are interested in getting more out of it. Cheers, Bill -- Bill Anderson Linux in Boise Club http://www.libc.org Amateurs built the Ark, professionals built the Titanic. Amateurs build Linux, professionals build Windows(tm).