Twinned Hosting

[Julian Price]

Dan Ros wrote:
> On Fri, Apr 17, 2009 at 7:38 PM, Julian Price <clug at jul17pri.co.uk> wrote:
>>>> To be honest I don't quite get what it's about. Sounds interesting
>>>> though.
>>> It needs a diagram really.
>> I have added a diagram to my 'Twinned Hosting' article at...
>>
>> http://www.julianprice.org.uk
>>
>> ...and rewritten it to make it more readable, hopefully.
>>
>> If you are interested in rock-solid low-to-medium traffic web-hosting for
>> dedicated PCs then please give it a read.
>>

> Few things:
These are some good points...

> If a server fails, it might well have been fixed by the time the
> administrator has noticed, changed the DNS, and the changes have
> propagated,
I should have made clear that I'm not advocating automated fail-over.

You're right, usually there's a faulty router or a power failure or a 
DoS attack or some maintenance going on somewhere and the problem goes 
away quickly.  Otherwise, once the administrator is alerted to a 
problem, they investigate it and can usually fix it.

So the idle server is only activated in a genuine disaster.

The DNS propogation time can be reduced by short TTLs.  I think a 1 hour 
TTL is reasonable.  ISPs used to ignore anything under 24 hours but in 
these days of chap & fast bandwidth I think that's disappearing.


> Also, only having occasional rsyncs will mean you may still lose data
> if a server goes down.
Yes, if the twins are sync'd nightly, then up to 24 hours of changes 
could be lost.  But this is the same for conventional nightly backups.

There's also the option of syncing more frequently, or even continually 
with rsync's throttled bandwidth option.

But however frequently they are sync'd, there'll be some data loss 
unless we use an option like DRBD.

> And a server going down in the middle of a
> rsync to its mirror could have messy consequences...
The idle server always has 2 copies of the virtual disk file.  One is 
for syncing and one is running.  So if the active server goes down 
during the rsync, the running VM on the idle server is good for use. 
Step 5) touches on this.

Maybe you mean that the scripts would need some careful error checking 
and handling to make sure that everything is cleaned up properly, ready 
for the next attempt.  Leaving the database lock on would be disastrous. 
  Leaving the snapshot active would degrade performance, eat disk space, 
and foul up the next sync.  Yes, it could get messy if not handled properly.

> DRBD might be
> interesting for you to look at.
I looked at DRBD, but I was concerned that the bandwidth usage would be 
too high if every disk write is mirrored.  With the twinning method, a 
sector is only transmitted once even though it was written many times.

> A safe way to do this with VM's is to use the built in
> replication/failover features in Xen/VMware.
I will take a look at that.

> By the way, what did you use to make the snazzy diagram?
The diagram was done for me by a web designer at 
http://www.dice-design.co.uk who I happen to be collaborating with on 
another website project.  I think they used illustrator.  I'll add a 
credit for them.

Thank you very much for your suggestions and feedback.

Julian