Kolab numbers.

[Bo Thorsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 08 April 2004 14:13, Luca Villani wrote:
> Alle 09:06, mercoledì 7 aprile 2004, Bo Thorsen ha scritto:
> > > Did any of you tested Kolab in a clustered/HA architecture?
> > > Did you think Kolab working fine in a such environment?
> >
> > There is no support for clustering in Kolab1.
>
> This is a bad news, I like kolab.
>
> > One of the things we're working on for Kolab2 is to add multilocation
> > capabilities of the mail and LDAP parts. Multilocation is not exactly
> > clustering, I know.
>
> No, it isn't the same thing.
>
> > Kolab2 do not have any plans that will help you with failover
> > capabilities, but clustering should not be necessary.
>
> Clustering is a must in an HA scenario.
>
> Let me explain a possible failover architecture.

... and clustering is not the same as failover.

> We have two machine (kolab-a and kolab-b), everyone tith two ethernet
> cards. The firts ethernet card of every server (kolab-a.eht1 and
> kolab-b.eth1) is exposed on big internet, and every server has a public
> ip address (x.y.z.1 and x.y.z.2) but *only* the main server has a
> second public ip address (x.y.z.3), the adress of the workgroup server.
> The first server (kolab-a) is up adn running, and *all* kolab
> components are up and running. The second server is up and running but
> have *only* openldap up and running, slurping user data from the first
> server.
> The totality of kolab istallation (without openldap database!) is
> replicated via a network file system like Intermezzo
> (http://www.inter-mezzo.org/) on the *second* ethernet card of every
> server (kolab-a.eth2, kolab-b.eth2), ie in a not internet exposed
> channel.
> Finally, we have heartbeat on all server.
>
> If the first server go down, heartbeat fier up a full kolab server on
> the second server, and attahch the main ip address (x.y.z.3) to the
> first ethernet card of the second server.
>
> In this scenario, can cyrus work on an Intermezzo shared storage? I
> know it don't work on NFS...

I think you hit the only possible problem nail spot on here. I can't 
answer that question for you. When you do figure out if it's possible or 
not, please mail the info here. That will be very useful for all of us.

I don't see any other problems in the scenario you describe.

> And in this scenario (cyrus working on top of a network shared
> storage), why can't I running two *separate* server working toghether?

Now you're getting very close to what we plan on doing. We don't have any 
failover involved in the multilocation setup, but each of the servers 
will have a full replication of the other machines. But we will still 
maintain a master server, which makes our future solution a bit different 
still.

> > A fairly new Kolab server will happily handle 10.000 users, so even
> > though your machines might have a bit of age, 300 users is just not a
> > problem.
>
> You don't know my commercial/marketing cow-workers... :-)
> 2 MByte emails is a normal job, only for asking "Hi, how are you?"...
> :-(

I stand by my promise. You will not be able to bring Kolab down with 300 
users. No matter if that's 300 2MB per mail senders.

But you might want to have very high performing network cards :-)

> > It is generally a problem for Kolab migration from Exchange, that
> > companies try to use their Exchange requirements directly on Kolab.
>
> We are not an exchange based company, only commercial/marketing guys
> are on top of an exchange server.
> But we are planning to migrate *all* our users (exchange users ad
> postfix users) on top of a groupware server: our actual mail server is
> a single dual processor machine, with an average load of 0.90, and our
> exchange server is an identical machine, slow down all the time.

Bo.

- -- 

     Bo Thorsen                 |   Praestevejen 4
     Senior Software Engineer   |   5290 Marslev
     Klarälvdalens Datakonsult  |   Denmark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFAdV6pmT99lwfUS5IRAs7pAJ4o9TXWRAFMgsSA5G3t7LT87xJQrQCfWyve
7Ea36Jw0Ao4/1o3022F3BmE=
=IzJ/
-----END PGP SIGNATURE-----