|
Hi Volker!
> If you give your domain e.g. yourdomain.com more than one IP e.g.
> Datacenter1 : IP = 123.123.123.1
> Datacenter2 : IP = 146.234.12.2
> the DNS performes a round robin loadbalancing on DNS -> IP resolving.
I have had that idea as well. But just help me understand what problem
this solved and which it doesn't:
> The first time a webbrowser accesses yourdomain.com it will get the
> first IP
> and your customer lands in DC1. If the next webbrowser accesses
> yourdomain.com
> it will land in DC2. Next in DC1 and so on.
That will for sure distribute load. But if one of the DCs (or one of the
servers) goes down, doesn't that mean that only every 2nd customer will
see our site while every other customer will end up with a timeout?
We had also been asking ourselves if we could have a mechanism where the
DNS servers will receive a heartbeat from the actual servers and just
switch off A records for servers which are currently unavailable. But
the problem with that is caching nameservers. AFAIK even if we would set
the TTL on our nameservers to 10 minutes to make sure that a cached
record for a server that died will expired after no more than 10
minutes, I understand for caching nameservers at any ISP they decide how
long they will cache the record or not.
Regards,
Torsten
Dr. Volker Jaenisch schrieb:
Hello Thorsten!
Torsten Schlabach schrieb:
Now if we want to build a reliable service on the Internet (say a
website, for example) we can have one A record for www.oursite.net point
to one IP address only. So we would want that IP address to
transparently fail over between two data centers.
One way to achieve this is to use the DNS.
If you give your domain e.g. yourdomain.com more than one IP e.g.
Datacenter1 : IP = 123.123.123.1
Datacenter2 : IP = 146.234.12.2
the DNS performes a round robin loadbalancing on DNS -> IP resolving.
The first time a webbrowser accesses yourdomain.com it will get the
first IP
and your customer lands in DC1. If the next webbrowser accesses
yourdomain.com
it will land in DC2. Next in DC1 and so on.
The only problem with this approach is to assure that the DNS TTL
settings are
long enougth so that a typical costomer will not be switched from DC to
DC within its actual session.
A second and from my point of view the most important is the need for
synchronisation of
your data e.g. your databases and the filesystem over the WAN between
the DCs.
The databases you can share across the two locations using a sequoia
DB-Cluster for e.g. MySQL, PGSQL databases.
The filesystem mirroring can be done using DRBD0.8 and a cluster
filesystem.
We have done some testing in that direction. This approach is due to the
synchronisation not ideal
for high traffic sites with many changes in the shared filesystem or the
shared DB-Cluster.
If you have a low/medium traffic site with extreme need for high
availability this scheme may help you.
But please be warned - this approach is definitivly not the cheap one.
Such a WAN distributed Cluster
is in the order of $100.000 and more.
Best regards,
Volker
| 