Building so a breakage does not stop you

The most familiar form of distributed processing is the client-server system: an arrangement that splits the roles into the side requesting a service (the client) and the side answering it (the server).

A browser and a web server are exactly this. The browser only says "give me this page", and building the contents is the server job.

What matters is that this is a kind of distributed processing, splitting up functions and placing them apart. Rather than doing everything inside one machine, the work is cut up by service and given to different machines.

A similar-sounding term is peer to peer, where no side is fixed as asking or answering and every machine behaves as an equal. Tell them apart by whether there is a server.

The server-side work can be split further. A common way is into three, giving the three-tier client-server system.

• Presentation tier … showing the screen and taking input. The browser handles it
• Function tier (application tier) … the business processing. The AP server handles it
• Data tier … storing and retrieving data. The DB server handles it

The form before this was two-tier. There the client also held the business processing, so software had to be redistributed to everybody terminal each time one piece of processing was corrected. On top of that, SQL statements flew straight from the client to the DB server, adding to the traffic.

Go to three tiers and the business processing gathers on the server side. All that is left on the client is showing the screen, so terminals can be light and a correction on the server takes effect for everybody.

Take three tiers to its conclusion and all the client does is put pictures on a screen. In that case there is no need to keep data on the terminal at all, which is the idea of the thin client.

Processing and data both live on the server, and the terminal in your hands handles only input and output. Often it is built without external storage such as a hard disk.

Where this pays off most is security. No data remains locally, so losing the terminal leaks nothing. What has to be protected gathers on the server, and hardening that lowers the risk in one go.

There are weaknesses too. Without communication to the server nothing can be done, and if the server gets busy everybody slows down. It is an arrangement that trades ease of defending for a heavy dependence on the server.

When the processing can no longer keep up, there are broadly two moves.

• Scale up … replace the machine with a higher-performance one. Still one machine, but stronger
• Scale out … add machines. Each stays as it is and the numbers do the work

Once you have scaled out, something has to hand out incoming work to the servers. That is the load balancer.

A load balancer spreads the processing evenly, so no machine sits idle and you can add more later to grow the throughput. That is a load balancing cluster.

Scaling out suits work where the same processing can be run side by side. Read-heavy processing splits easily. Conversely it does not suit one large piece of processing that cannot be divided, nor anything write-heavy where reconciling the disagreements costs a lot.

Machines break eventually, so having two of the same thing ready is the idea behind redundancy (duplication). Similar-sounding methods line up here, so sort them out.

• Simplex system … one line only. No spare
• Dual system … two lines carry out exactly the same processing at the same time and their results are compared. A disagreement reveals a fault. If one breaks it is cut off and the rest carries on (degraded operation)
• Duplex system … one side is live (the active system) and the other is the spare (the standby system). When the active side falls, it switches to standby

Those two are the ones that get muddled. Dual means both are doing the same work and checking each other. Duplex means one works and one waits.

Both have two lines, but the aims differ. Dual is for when you want to protect the correctness of the result as well; duplex is for when you want to protect not stopping.

The "spare" of a duplex system comes at different temperatures, and the name changes with how ready the standby is.

• Hot standby … the standby has the same program already started and waiting. It watches whether the active side is alive and takes over immediately when it falls
• Warm standby … powered on, but the business program is not running. Switching takes a little time
• Cold standby … the standby is switched off. It is started and brought up after the breakage, so it takes longest

Ranked by not stopping, the order runs dual, hot standby, cold standby, simplex. Think of it as the warmer the spare, the sooner you are back, and there is no order to memorise.

An arrangement presenting several servers as one is a cluster. The form with a standby is an HA cluster; the form sharing the work through a load balancer is a load balancing cluster.

The two have different aims. An HA cluster is for keeping the same performance through a breakage, and its standby usually sits idle. A load balancing cluster is for using every machine fully, so losing one makes life harder for the rest.

Redundancy is the tool; on top of it sits a design philosophy about how to protect things. Here are the four the exam muddles most.

• Fault tolerant … even with a partial failure, the necessary function of the whole is maintained. Multiplied up, so the effect of a failure never gets out
• Fail soft … on a failure, keep running even if functions have to be dropped. Survive at lower performance (this state is degraded operation)
• Fail safe … on a failure, fall to the safe side and stop. Not causing harm takes priority over carrying on
• Fool proof … arrange things so that a mistaken operation by a person causes nothing abnormal in the first place. The subject is not failure but mistaken operation

Tell them apart like this. First split is it about a breakage or about a mistake? If it is about a mistake, it is fool proof.

If it is about a breakage, look at whether it continues or stops. Continuing with less is fail soft; stopping safely is fail safe. And the larger goal of never letting the whole go down is fault tolerance.

Of all the parts that break, disks break most. So bundling several disks and presenting them as one is RAID.

The ways of bundling are numbered, distinguished by the combination of how the data and the redundant bits are recorded and where they are put.

• RAID0 (striping) … the data is divided finely and written spread across several disks. It can be read and written in parallel, so it is fast. But there is no redundancy: one disk fails and everything is lost
• RAID1 (mirroring) … the same content is written to two disks. One can fail and the other carries on. In exchange only half the capacity is usable
• RAID5 … the data is spread in blocks and the parity for reconstruction is also spread across several disks. Up to one disk can be reconstructed from the rest

Remember it as 0 for speed, 1 for safety, 5 as the compromise.

What RAID5 does well is not gathering the reconstruction data onto one disk.

With parity held on a single disk (RAID4), every write necessarily reaches that one disk and it becomes a bottleneck. RAID5 spreads the parity too, so that bottleneck does not arise.

The question of how many disks also comes up.

• RAID1 holds the same content on two disks, so it needs twice the capacity you want to use. To use 4 TB with 1 TB disks takes eight of them
• RAID5 uses one disk worth of the n for parity, so the usable capacity is (n - 1) disks worth

"How many disks are needed" falls out of applying these relations plainly.

Up to now it has been about adding machines. But you cannot always add physically, and that is where virtualisation comes in.

Virtualisation is the technology that makes one physical server look as though it contains several independent computers. Each virtual server inside has its own OS, and they do not interfere with one another.

The gain is sharing out performance that was going unused. If three servers are each using 30 per cent, putting them together wastes less. Fewer machines means less floor space and a smaller electricity bill.

What to watch is that when one physical server breaks, every virtual server inside it stops. The remaining physical servers take on the freed load, and their own load rises accordingly. Past what they can manage, they enter degraded operation with functions pared back.

Have somebody else do that virtualisation on their own large installation, and rent as much of it as you need: that is cloud computing, a service providing computing resources across a network.

The name changes with how much you rent, splitting on how much is their job.

• IaaS … you rent as far as the hardware and the execution environment. From the OS upwards you install and manage it yourself. The greatest freedom
• PaaS … you rent as far as the OS and the middleware. What you provide is only the application. You cannot touch the foundation
• SaaS … you use something where the application is already built. There is nothing to provide; you just change settings and use it

The middle letter of the name holds the answer. I is infrastructure, P is platform, S is software, and everything up to that letter is theirs.

SaaS is the easiest, but being ready-made it is hard to fit to your own particular needs. IaaS is the freest, but you look after the OS yourself. Ease and freedom trade against each other.