[prev in list] [next in list] [prev in thread] [next in thread] 

List:       info-cyrus
Subject:    Re: [POLL] virtual domains and Murder
From:       Michael Fair <michael () daclubhouse ! net>
Date:       2002-07-26 7:49:30
[Download RAW message or body]

Fabian:
Interesting idea, but I think it's overkill
and actually adds complexity where it doesn't 
need to be.

First, this thread is explicitly talking about 
IP based virtual domains in relationship to a 
Murder.  The problem is that since there are
multiple machines that a client could be talking
to, there is no easy way for Cyrus to know
which domain the end user was trying to contact.


I fail to see how your comments relate to that 
topic at all.

> My company has been testing an idea that is a little bit more wild:
> load-balancing by network topology using Murder. 

I fail to see why this requires a murder versus
just an IMAP proxy like perdition. 

> In short, the idea goes
> as follows:
> 
> Users can genererally be divided into two groups: those that read their
> mail from the office (desktops) and those that read their mail on the
> road (laptops).

True.
 
> Given a company that has a number of offices and a number of people
> working from various places, it would be clever to position their
> mailboxes according to where they are most of the time. Hence, you could
> place a cyrus Murder backend at each office. Each backend could be as
> powerful as needed with regard to the number of users you need to
> support at each location. Each backend would include those mailboxes
> that belong to the people working at that location.

Or you can have one murder at the home office with a large
pipe and all satellite offices have a local IMAP proxy
which will act just like a web proxy in that the mailboxes
will be cached locally at the proxy and sync with the
murder at the home office.  This is better in that the
end user can change offices and the system setup doesn't
need to change at all.

The person could setup a proxy in their home, and the
office and have local access to their mailbox in both
places if desired.

> The mobile users would benefit from a backend positioned close to their
> connection point. For example, if they use GSM or GPRS to connect, the
> backend would be hosted by the ISP that provides their network service.

Again why would they want to host the backend when
a simple proxy would do... This is especially important
for mobile users who will roam around a lot.  Having
their mailbox's home jump from server to server while
they roam around seems to me to be asking for trouble.

Put the master home at the home office, then just use
proxies to simulate local access.
 
> Frontends would also be positioned at various places. Using DNS SRV
> records, the clients find the correct front-end(s) to connect to.

I fail to see how an SRV record is going to be any
different than a standard A record to determine the
correct front end to connect to.  I don't know all the
specifics of an SRV record, but from what I can the 
only real advantage is you can stuff both IP and port
in the response which isn't an issue in this case.

If the server is somehow giving different responses 
based on geograhpy of the requesting IP, then I see 
no reason that same algorithm couldn't be applied to
an A record.  DNS caching is a problem... Perhaps SRV
records aren't allowed to be cached in the same way.

 
> The advantage of using Murder would be that you can add and remove
> front- and back-ends if an office opens, closes or moves, shrinks or
> grows - without having to worry about configuring your MTA to use some
> look-up technique to determine where the mailbox is. You could move a
> mailbox from one backend to another when an employee changes locations.
> You could scale up and add back- or front-ends when the number of
> mailboxes grow.

This is even easier with a proxy setup.
When an office opens/closes you simply add/remove the
proxy server (this would be your "backend" server).  If
it grows, nothing needs to be done except setting up the
new users to proxy through the local box.
 
> Adding virtual domains to the mix would allow the whole system to take
> advantage of a few central servers, owned by an ISP/HSP, that host some
> mailboxes of all domains, and adding servers located at the customers'
> premises as needed that host most mailboxes of the customer's domains
> (reducing network traffic going over the slowest links).

Again, ISP/HSP sets up a centralized rackmounted room with
one or more mail servers, then just sets up an IMAP proxy
at the customer premise.  Not too mention the whole concept 
of an ISP putting something more complex than a router at 
a customer prem is really stretching it.  Customers would
have to purchase or lease the box that's going to act as 
the server and in service agreements where they can afford
that purchase/lease the bandwidth is usually large enough
to make it a mute point as there are no significant gains
in setting up the proxy (except perhaps in a per byte 
tarriffed environment to reduce redundancy).  Then there's
the whole issue of who owns the box, it's always best if
the customer owns the box because then they can just pack
up and leave with it.  Whereas if the ISP owns it they
now have to track it and manage it (which they have to
charge the customer for, which the customer doesn't usually
like) and in the end usually causes more heartache than
it solves.

Again a murder only complicates this setup.
Assuming this ISP is doing IP based virtual hosting then
it will have a set of let's say 5 mail servers that manage
the load of all their virtual domains.  Then when it makes
sense, or as a recommended practice to their customers they
help them setup a local IMAP proxy for their domain.
Heck using a decent firewall you could probably even 
set it up as a transparent proxy and the customer will
use the proxy when they're at the office and then use
the ISP's server directly when they're on the road.


A murder environment is identical to this setup in 
regards to virtual domains.  The only time this would
be an issue is if the ISP had a single customer that
was bigger than a single server.  In that case they
are going to have to buy more servers anyway, so buying
them and setting up a murder dedicated just to them 
is exactly what those servers were purchased for.  
They will not be putting any other clients on those 
servers because that mutes the point of why that client
needed more than one server to begin with.  New clients
will go onto the existing standalone servers which 
do support IP based virtual hosting while this large
client (or clients) are tied to their respoective
murder (or murders in the case of multiple large
clients).  Think about.  These machines need to be
purchased and their resources allocated.  There is
a very negligible price to pay for tying a domain's
mailbox to a single server.  That single server will
host many domains wholly and completely.  If the ISP
should get more clients than that server can support
they get another one and then they have two Cyrus
servers and they can choose between the two when
new clients come in.  This works because there is
no need for users on one server to access mailboxes
located on the other server.  They now get the dream
come true of a client with a bazillion users.  They
go buy 6 servers, 2 front ends and 4 backends set up
as a murder and dedicate those 6 machines to serving
those bazillion end users.  Even in this scenario,
the only things the murder gets them is the opportunity
to put Shared Folders on any of the backend servers
and have them be accessed equally among the bazillion 
users, (in rare cases) any end user could authorize 
themselves as any other user in the domain, and an
administrator could administrate any of the bazillion
accounts by contacting either frontend server.
Other than those three things the setup is almost
identical from an end user perspective as if they just 
made 4 standalone servers and split the bazillion 
users among them without any front end servers at all.


> Of course, there are a number of issues such as DNS SRV support in
> clients, easy and safe moving of mailboxes between backends and so on.

Both of which are solved by using proxies instead of
real backends.  If SRV records do indeed prove to be
useful for this, then you only need ensure that the
proxies support SRV records.  Since the choice in proxy 
software is something you have control over, and in the 
Open Source world even source control over, it is both
realistic and doable to use SRV records for the task
of proxies determining what server to contact...

-- Michael --

[prev in list] [next in list] [prev in thread] [next in thread]