On 11/26/07, Ronie Gilberto Henrich <[EMAIL PROTECTED]> 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
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
