13 messages in net.sourceforge.lists.courier-usersRe: [courier-users] RES: RES: Couri...
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: RES: Courier Backup / replication pointActions...
From:gor...@bobich.net (gor@bobich.net)
Date:Nov 26, 2007 7:28:43 am
List:net.sourceforge.lists.courier-users

On Mon, 26 Nov 2007, Ronie Gilberto Henrich wrote:

Hi Jay, Hi Gordan,

I will explain better our today's setup, I cannot see/understand how your solution could fit/work in our environment: 2 "external" servers: they are firewall, LVS and load balancing; 2 "internal" servers: they are the courier servers;

* The 2 "internal" servers replicates data between each other using unison; * We don't have a SAN and/or NAS, and we don't want use a SAN/NAS/storage, here are the reasons: 1) Price (it is a very expensive solution);

Only if you pay a premium for a badge on the front of it. You can get 24TB in 4U for about 7,000 GBP if you build your own, or about 15,000 GBP if you buy a ready-made one (unless you demand a price-bloated brand name on it).

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; 3) It means an even more expensive solution;

I thought your requirement was first and foremost for a redundant solution. I must have misunderstood. But if that's not a requirement, why do you need replication?

4) Also we cannot forget that using more equipment, means more energy consuption; 5) Oh, not to forget we need more room for the SAN/NAS/storage solution comparing to a simple "service replication" solution.

Depends on how you organize your servers. If you DIY a solution there is nothing to stop you from setting up DRDB across your cluster instead of using a SAN, and then running GFS on top of that in the cluster. And any server can become a SAN appliance without any real difficulties.

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?

Sure, I understand that. But in order to achieve what you want you need to implement a shared replicated file system, which gives you several well understood and already implemented options. Re-inventing it on the application level doesn't seem justified.

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?

You cannot do that with NFS, unless I've missed something important in your setup. You need to set up DRDB/SAN on both servers, run GFS on top of that, and then NFS export a share on GFS, if you want to use NFS. DRDB+GFS will take care of the file system replication for you in real-time.

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.

Seems vastly over-complicated when there is already a solution available. If you want an undo/redo log, use a stackable versioning file system like Wayback, on top of GFS. But for a mail storage system, that is probably a complete waste of time because of the nature of the application.

Gordan