Fail-Proof client-server architecture for thin client systems.

[johno]

Dear Techs,

 

Thin clients bring about incredible security which inturn cuts down on

it support cost and increased up time and hence you have greater worker productivity as a result. And the benefits keep going with time.

 

Isnt that wonderful new.

 

But as we all know there is a singlepoint of failure which could affect every user.

 

I would like to know what methods are used in best practise that counter this problem that is posed by thin client - fail proof client-server architecture.

 

Your contributions will be greatly appreciated.

[Duke]

Okay, I'll bite:

 

Redundant SANs in separate locations on site. These are synchronously mirrored and have redundant, high-speed links. The SANs themselves have redundant hardware, power feeds to each PSU come from different supplies and different PDUs. You also have power generation facilities on-site in the case of a site-wide power outage. RAID with a high level of redundancy is used for the disks and each SAN has clustered heads with instant failover support. The SANs are used to store the thin client virtual machine images and VMware (or similar) clusters are used to host these virtual machines. The VMware clusters have failover and Fault Tolerance for instant failover in the case of a host failing, and the two groups of clusters are in different locations on site with redundant links so that one entire cluster can fail over to the other. All your edge locations with thin clients have redundant links back to the core and these are configured to failover automatically in the case of a switch failure.

 

http://www.hardenhuish.wilts.sch.uk/avatar/redundant.jpg

 

Your virtual machine images are backed-up and uploaded to cloud-based storage and a cloud-based VMware instance, your have a redundant, high-bandwidth VPN connection to this and hardware at your end that will route the connections over the internet to present the cloud-based thin client images directly to your thin clients.

 

Now all you need is several million pounds.

Edited November 25, 2010 by Duke

[budgester]

Which single point of failure are you talking about ?

 

Power ? Networking ? Only using a single Terminal Server (Which would be braindead for an amount of users over 10).

 

Are you looking to implement, have implemented, can you give us more info ?

[budgester]

Now all you need is several million pounds.

 

Your not really taking into account Kim Jong Ill, Apparently he has nuclear weapons and is a bit unbalanced, so I don't think this will continue to work through a nuclear war.

 

Yup, Kim is definately the single point of failure.

[Duke]

Your not really taking into account Kim Jong Ill, Apparently he has nuclear weapons and is a bit unbalanced, so I don't think this will continue to work through a nuclear war.

 

Yup, Kim is definately the single point of failure.

 

Hmm, good point. Okay, the cloud is hosted in either North Korea (they won't blow themselves up, but USA might I guess) or Sweden (no one messes with Sweden).

 

[dhicks]

But as we all know there is a singlepoint of failure which could affect every user.

 

How do you mean, exactly - the network connection, or the server? You can simply have multiple servers for your thin clients - if one fails, the load simply gets distributed to ther other server(s).

 

--

David Hicks

[johno]

I basically mean the server, if it has to fail there should be a secondary dns server with redunadant data

Or something this is what I mean!

[johno]

I only have twenty five users on my network so its pretty small! I don think it will be that complicated.

[dhicks]

I basically mean the server, if it has to fail there should be a secondary dns server with redunadant data

 

Failover between two servers is easy enough - just use DRBD or similar to mirror VM disk images between two physical machines.

 

--

David Hicks

[johno]

thanks dhicks, by vm u mean virtual machines right? im really new to this concept btw.

[dhicks]

thanks dhicks, by vm u mean virtual machines right? im really new to this concept btw.

 

Yes, sorry - VM == Virtual Machine. Each virtual machine running on a physical server will need somewhere to store its data - when the VM starts, it'll expect to have a harddrive available. In many cases this is done with a simple file, although in bigger systems designed for use by many users you might assign a VM an actual, physical harddrive or RAID array to itself, depending on just how much disk performance your VM needs.

 

--

David Hicks