13 messages in net.sourceforge.lists.courier-usersRe: [courier-users] RES: Courier Back...
FromSent OnAttachments
Sam VarshavchikNov 24, 2007 7:15 am 
Ronie Gilberto HenrichNov 24, 2007 9:24 am 
Jay LeeNov 24, 2007 3:39 pm 
Jérôme BlionNov 24, 2007 7:11 pm 
Ronie Gilberto HenrichNov 25, 2007 9:36 am 
Jay LeeNov 25, 2007 10:37 am 
gor...@bobich.netNov 26, 2007 2:25 am 
Ronie Gilberto HenrichNov 26, 2007 7:12 am 
gor...@bobich.netNov 26, 2007 7:28 am 
Jay LeeNov 26, 2007 8:18 am 
gor...@bobich.netNov 26, 2007 8:27 am 
Ronie Gilberto HenrichNov 26, 2007 10:23 am 
gor...@bobich.netNov 27, 2007 1:40 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [courier-users] RES: Courier Backup / replication pointActions...
From:Jay Lee (jl@pbu.edu)
Date:Nov 26, 2007 8:18:56 am
List:net.sourceforge.lists.courier-users

On 11/26/07, Ronie Gilberto Henrich <ron@ronie.com.br> wrote:

1) Price (it is a very expensive solution);

No not really, you can use OSS solutions like GFS or ZFS to achieve this. you're already talking about having redundant storage, why should it cost any more at the filesystem or block level than it would at the app level?

2) To have a SAN/NAS/storage "SPOF free" we have to

duplicate it, having 2 storages, 2 SAN switches, and at least 2 network cards exclusively for the SAN/NAS/storage solution;

Yes that would be the "professional" way, but as I said, you could acheive a similar setup on a tight budget.

3) It means an even more expensive solution;

No, as I've said, I don't think it does. In fact, it'd be much cheaper to use existing and tested NFS/GFS/etc code than to write your own.

4) Also we cannot forget that using more equipment, means

more energy consuption;

Why does it require more equipment? Have you bothered to look into GFS or ZFS at all?

5) Oh, not to forget we need more room for the

SAN/NAS/storage solution comparing to a simple "service replication" solution.

Again, I don't see why doing the replication at the block or filesystem *must* require more hardware.

My idea is to optimize the use of resources. If we don't need to

replicate everything, why don't replicate just what we need?

As I wrote in my last email, what's stopping you from just NFS exporting the Maildir's? You didn't respond to that.

Jay, about the NFS solution, how does it work regarding syncronism?

I mean, will the files in the 2 servers be always the same?

Example, courier saves a file on server 1, at the same time will that file be updated in server 2?

Yes I believe so with GFS or ZFS, why don't you spend some time researching their merits?

My idea was to contribute with the courier project including a

feature where will allow it to save the files in 1 or more backup/replication points. The idea was not to do everything inside courier, I was thinking to include an option where courier could generate a kind of "redo log" (similar to oracle) and an extra package would read those "redo log" files and do that on the replication servers. With this "redo log" idea, it will be always possible to have the servers syncronized, even if we put a server in maintenance mode, after coming back to online mode, it will run the "redo log" files to be in syncro with the other servers again.

Ultimately it's Sam's decision since it's his project, maybe you should appeal directly to him instead of all of us debating endlessly here...

I don't want to re-invent the wheel.

I am just suggesting to add an extra truck (server) and distribute the weight between them. Then in the case one truck fails, the drivers have just to attach the brocken truck's load to the other truck and let it continues the journey.

Jay

-- Jay Lee Network / Systems Administrator Information Technology Dept. Philadelphia Biblical University