[Zope] Will ZEO solve my problem?

[Bill Anderson]

This seems more germane to zodb-dev. cc'ed there for further replies to
go there.


On 03 Jul 2001 07:21:09 -0500, Kyler B. Laird wrote:

> >>If you are running the ZSS on Linux, you can use a network block device
> >>setup that establishes a raid1 over the netwrok, and have it do a split
> >>read/write such that it only reads from the primary, but writes over the
> >>raid.
> >
> >Have you tried this with FileStorage? Testing this configuration is
> >approaching the top of my to-do list. I am a little worried that it
> >may not be entirely stable in high-write usage, such as during a pack.
> >(although at the moment that is just unsubstantiated FUD)


Testing with Filestorage really is just icing. The process _does_ work, I know people using it for always-on hot-backup. it occurs at the OS level, and as far as FS is concerned, it just looks at a file on the fs. it has no clue that the fs is actually running on a RAID device, let alone across a network.
 
> NBD could cause performance problems, but in
> theory it should work.  (It's pretty cool.)  It
> should have very little network overhead beyond
> that of the "tail" method, but it would support
> writing to random locations within the file.
> 
> It would not be a simple cross-platform solution.

Thus the 'if on Linux remark', but then again, remember this is only for the ZSS, and only until ZEO Replication is accomplished. The ZEO Clients can stil be on anything ZEO runs on.

> In the most basic usage, it would also be
> blocking; it would slow down the server.

How do you figure this? From the server's standpoint, it is just writing to a file on a filesystem. Writes do go out on the network, but they occur simultaneously. Reads are limited to 'local', so there is no performance loss there. I don't know where you get this 'blocking' bit. Writes may suffer slight performance drop in writing speed, but will not increase the 'blockiness' of ZSS. Any replication method that occurs in real time, or even damned-near-real time will cause this to happen.

> >If the network block device doesnt work out, I am considering patching
> >FileStorage to distribute writes across the network, and only allow
> >the transaction commit to complete once data is consistent across
> >multiple remote mirrors.
> 
> This would be great, and I do hope that you do
> it.
> 
> I'm still interested in a simple method that
> does not force the primary server to wait for
> updates to be made.  If someone uploads a 1GB
> PDF file to my primary server, I'd rather not
> wait while every backup is made.  I wouldn't
> mind it for my on-site hosts, but I'm
> willing to sacrifice some transactions in a
> (rare) failure than have them always delayed.


Hmmm, seems you may be misunderstanding ZEO and backing up/replicating of the ZODB. If someone uploads a 1gb PDF, you _will_ be waiting a while for that update to span networks in replicated ZSS, just as you will be waiting for that PDF to be uploaded in the first place. Your ZEO Clients will only be waiting on the server to receive the file. So, with a single ZSS, and 5 ZEO clients (let's pretend they are zope servers), the file is uploaded once. now, when a ZEO Client receives a request, it will indeed request the data from the server, and ship it to the client. There is possibly, depending on network bandwidth, a delay, but unles your the end-user browser is on a network connection to the zope server that is as fast or faster than the ZSS->Zope connection, they will not notice a difference. I don't think ZEO was meant for such large file transfers anyway, but I could be wrong.

In any event, distributing large files across a network will always cost at a minimum, network delays, regardless of the method used. if there are network delays between primary and any secondaries, and the relay is not done 'offline' (that is to say, not in full sync with the primary), there will be on the primary. The reason is that if you are, in your example, uploading a 1Gb file, and ZEO is replicating that in sync, it has to monitor the progress, in the event that a) network data corruption occurs, or b) user cancels the upload (or it times out, or similar activities/events), at which point it needs to cancel the transaction across primaries.


In NBD, you would only be waiting once, as the writes occur in unison. In replicated ZSS, I cannot say, as I don't know much of the details (does anyone ;") ?


Bill