Modular Systems: The Evolution of Reliability

Overview

The text is largely qualitative and draws on analogies from multicellular life, RAID storage and blade servers. Five advantages of modular design are listed: ability to scale, simpler duplication, specialisation of modules, rapid adaptation and fault tolerance, which is judged the critical one. The paper contends that the rule 'more parts means more failures' misleads when the system can keep running after a module fails. The authors use this framing to challenge the intuition that adding parts by itself lowers reliability.

The RAID case is concrete: it was proposed in a 1988 Berkeley paper, the first arrays appeared in 1990, and its market success came mainly from fault tolerance rather than the speed it was designed for. The same logic is carried to physical infrastructure: if a single large UPS protecting the whole data centre fails, all racks drop, whereas with one UPS per rack a single failure drops only one rack. If the IT layer can survive the loss of racks until three fail, three distributed UPSs would have to fail simultaneously, which is far less likely than one large UPS failing.

In power and cooling, fault tolerance can come from redundancy of whole units or from internal redundancy, such as extra power modules in a UPS. IT equipment changes every 2 to 3 years while traditional infrastructure is deployed once for the projected maximum load, a mismatch that modularity also reduces. The essay has no quantitative availability model, so it serves as design rationale and numbers should come from quantitative sources. The authors therefore present modular power and cooling as both confining the effect of a failure and letting capacity grow alongside IT.

Key points

1. Five advantages of modular design: ability to scale, simpler duplication, specialisation of modules, rapid adaptation and fault tolerance (the critical one).
2. RAID was proposed in a 1988 Berkeley paper and the first arrays appeared in 1990; its success came mainly from fault tolerance, not the speed it was designed for.
3. If one large UPS protecting the whole data centre fails, all racks drop; with one UPS per rack a single failure drops only one rack.
4. If the IT layer survives until three racks fail, three distributed UPSs must fail simultaneously, far less likely than one large UPS failing.
5. Fault tolerance can come from redundancy of whole units or internal redundancy such as extra power modules in a UPS.
6. IT equipment changes every 2 to 3 years, while traditional infrastructure is deployed once for projected maximum load.

Using it in design

• In the availability model give each UPS and cooling unit a failure-domain attribute (racks lost on its failure) alongside MTBF, so users can compare one large UPS with distributed or modular N+1 options by blast radius, not just component count.
• Give UPS catalogue entries a modular flag and internal module redundancy (for example N+1 power modules).
• Highlight in the UI any single component whose failure drops the whole IT load.
• Use this paper as rationale only and take numbers from quantitative sources.

Who should read it

Designers and managers deciding between one large unit and a modular approach when choosing UPS and cooling architecture.

Publication details

Authors

Neil Rasmussen; Suzanne Niles

Publisher

Schneider Electric

Year

2011

Document number

WP 76

Document language

English

Source type

Manufacturer

Access

Free to read

Licence

Copyright retained; citation only — the publisher’s terms apply to the original document

Citation