About the current situation of distributed systems.

[一首诗]

Hi all.

Actually I know nothing about distributed system. But now I am facing
problem that drives me to this area.

I am developing a client - server system that could work separately but
if needed, could merge in to one system easily.

For example, we could sell the system to 2 different cities, but when
our customer needed, we could connected the 2 systems as if there is
only one system but more data and resources.

So I am think about use distributed system to solve the problem. When
the system needed to be connected, just build a distributed system and
run only one server program with 2 database instead of one.

I am not sure if the physical distance would be a serious problem if we
use distributed system.

The question might be quite inaccurate because what information I
should give.

Thanks a lot!

[russell kym horsell]

Post by 一首诗
Hi all.
Actually I know nothing about distributed system. But now I am facing
problem that drives me to this area.
I am developing a client - server system that could work separately but
if needed, could merge in to one system easily.

A single client/server is not really what is called a "distributed system".
It largely avoids many of the issues of distrobuted concurrency by
enforcing strict serialisation at the server end. All very logical and
very reasonable, of course.

Post by 一首诗
For example, we could sell the system to 2 different cities, but when
our customer needed, we could connected the 2 systems as if there is
only one system but more data and resources.

Having 2 servers at WAN distances will start to enter into the realm
we all know and love. :)
You probably now need to have some mechanism to keep the 2 servers "looking the
same" to the clients attached to either.
This is almost always not worth the effort if you think
of going this way for "efficiency" reasons.
If the 2 servers were completely isolated -- carried data for different
departments or customers or somthing like that -- then a client
connects to server A when required or B when required.
Client-end logic can be used to decide which servre to connect to.
This is a micro version of what distributed systems have to do.


Distributed systems generally try to push the logic of synchronising out
equally to each node in the network -- a system relying on 1 or 2 central
servers handling an indefinite number of client processes is not usually
throught of as "distributed". :)

Post by 一首诗
So I am think about use distributed system to solve the problem. When
the system needed to be connected, just build a distributed system and
run only one server program with 2 database instead of one.
I am not sure if the physical distance would be a serious problem if we
use distributed system.

Ahmdahl's Law needs to be consulted. A large latency between 2 servers
that may only need occassional synchronising is a loose-making situation
almost all of the time.
Gustavson's Law (how big can I make the problem/database to get some wins)
can only be looked at longingly in a situation as you describe. :)

Post by 一首诗
The question might be quite inaccurate because what information I
should give.
Thanks a lot!

[Chris Wilk]

Post by 一首诗
I am developing a client - server system that could work separately but
if needed, could merge in to one system easily.
For example, we could sell the system to 2 different cities, but when
our customer needed, we could connected the 2 systems as if there is
only one system but more data and resources.
So I am think about use distributed system to solve the problem. When
the system needed to be connected, just build a distributed system and
run only one server program with 2 database instead of one.
I am not sure if the physical distance would be a serious problem if we
use distributed system.

I would approach your problem with a help of grid tools and applications.

You can use metascheduler / grid broker
<http://en.wikipedia.org/wiki/Metascheduler> to distributed jobs
(application tasks) into 2 clusters (systems).
You will also need some data replication
<http://en.wikipedia.org/wiki/Data_replication> tools for moving data
from 2 sites to 1 site either periodically or on-demand.

If you have good quality network interconnections between these sites,
physical distance will not matter.

Best,
Chris

[Chris Wilk]

Post by 一首诗
I am developing a client - server system that could work separately but
if needed, could merge in to one system easily.
For example, we could sell the system to 2 different cities, but when
our customer needed, we could connected the 2 systems as if there is
only one system but more data and resources.
So I am think about use distributed system to solve the problem. When
the system needed to be connected, just build a distributed system and
run only one server program with 2 database instead of one.
I am not sure if the physical distance would be a serious problem if we
use distributed system.

I would approach your problem with a help of grid tools and applications.

You can use metascheduler / grid broker
<http://en.wikipedia.org/wiki/Metascheduler> to distributed jobs
(application tasks) into 2 clusters (systems).
You will also need some data replication
<http://en.wikipedia.org/wiki/Data_replication> tools for moving data
from 2 sites to 1 site either periodically or on-demand.

If you have good quality network interconnections between these sites,
physical distance will not matter.

Best,
Chris

[Chris Wilk]

Post by 一首诗
I am developing a client - server system that could work separately but
if needed, could merge in to one system easily.
For example, we could sell the system to 2 different cities, but when
our customer needed, we could connected the 2 systems as if there is
only one system but more data and resources.
So I am think about use distributed system to solve the problem. When
the system needed to be connected, just build a distributed system and
run only one server program with 2 database instead of one.
I am not sure if the physical distance would be a serious problem if we
use distributed system.

I would approach your problem with a help of grid tools and applications.

You can use metascheduler / grid broker
<http://en.wikipedia.org/wiki/Metascheduler> to distributed jobs
(application tasks) into 2 clusters (systems).
You will also need some data replication
<http://en.wikipedia.org/wiki/Data_replication> tools for moving data
from 2 sites to 1 site either periodically or on-demand.

If you have good quality network interconnection between these sites,
physical distance will not matter.

Best,
Chris