[Zope] Zope Myths?

[Bill Anderson]

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).