◇ OpenCyber Academy
Engineering · Chapter 3 · English

Chapter 3 — Physics for computing

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 3 — Physics for computing

Lesson map

Lesson 03 published. Map, example, EX007.

flowchart TD
  N0["Learning outcomes"]
  N1["3.1 Distance and latency"]
  N2["3.2 Zones and regions"]
  N3["3.3 Energy and heat"]
  N4["3.4 Hardware failure"]
  N5["3.5 Location and data protection"]
  N6["3.6 Shared hardware"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX007"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["3.1 Distance and latency"]
  N2["3.2 Zones and regions"]
  N3["3.3 Energy and heat"]
  N4["3.4 Hardware failure"]
  N5["3.5 Location and data protection"]
  N6["3.6 Shared hardware"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX007"]

[Learning outcomes]
    |
    v
[3.1 Distance and latency]
    |
    v
[3.2 Zones and regions]
    |
    v
[3.3 Energy and heat]
    |
    v
[3.4 Hardware failure]
    |
    v
[3.5 Location and data protection]
    |
    v
[3.6 Shared hardware]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX007]

Learning outcomes

You will (1) relate physical limits to cloud systems; (2) reason about latency, energy and failure in data centres; (3) understand why regions and zones exist; (4) connect physical location to data protection.

3.1 Distance and latency

Signals in fibre travel at roughly two-thirds the speed of light, about 200 km per millisecond. A round trip between regions 1,000 km apart costs at least 10 ms before any processing. meterhub keeps its database in the same region as ingest for this reason.

Ten milliseconds sounds small, but an application that makes twenty sequential database calls per request would add 200 ms if the database sat in another region. Users notice delays of that size. Physics sets a floor that no amount of engineering removes, which is why data placement is decided early in a design rather than adjusted later.

3.2 Zones and regions

Providers group data centres into availability zones (separate power and cooling) within regions. Spreading workloads across zones protects against a single facility failure; regions protect against wider events.

A zone failure might come from a power fault or a cooling problem in one facility; a regional event might be a major network outage or a natural disaster affecting several facilities. Spreading across zones is relatively cheap and handles the common case. Spreading across regions costs more, adds latency and complicates data protection, so it is reserved for services that truly need it.

3.3 Energy and heat

Computing turns electrical energy into heat. Data-centre capacity is limited by power and cooling, which is why providers price resources and why idle over-provisioned clusters waste money and energy.

Every idle node draws power and needs cooling even when it does no useful work. A cluster sized for the evening peak all day long wastes most of that energy in quiet hours. Autoscaling and right-sizing reduce both the cost and the energy used, which matters to an energy co-operative whose members care about efficiency.

3.4 Hardware failure

Disks, memory and power supplies fail at measurable rates. At scale, failures are routine, so cloud systems are designed to replace failed parts automatically. Verma et al. (2015) describe how Google's Borg handled machine failures as normal events.

At the scale of a large cloud, disks fail daily somewhere, so systems that treat failure as an emergency would be in permanent crisis. Borg's approach of rescheduling work automatically when a machine fails became a model for Kubernetes. For meterhub, it means pods should be written so that losing one and starting another elsewhere does no harm.

3.5 Location and data protection

Meter readings are personal data about household behaviour. Where data are physically stored affects which laws apply; Solent keeps readings in one jurisdiction, recorded in its data register.

Readings taken every half hour can reveal when a household wakes, leaves and returns, so they are personal data under most data protection laws. Storing them in one jurisdiction keeps the legal picture simple. The data register records where each data set lives, which lets Solent answer regulators and members accurately. Backups stay in-jurisdiction too.

3.6 Shared hardware

Workloads from different customers may share physical machines. Ristenpart et al. (2009) showed that co-residence could leak information, which drove providers to strengthen isolation; customers handle the rest through their own configuration choices.

Co-residence research showed that, under some conditions, one virtual machine could learn information about another on the same physical host. Providers responded with stronger isolation and placement controls. What remains for customers is their own configuration: who can reach their services, which secrets their workloads hold, and how their data are protected.

Worked example

Elena checks meterhub's zones: all ingest pods run in one zone. A zone outage would stop ingestion for 80,000 meters. She proposes spreading pods across three zones and estimates the extra cross-zone latency at under 2 ms, acceptable for ingest.

Synthetic case. Figures are synthetic and approximate.

Errors and limits

Physical estimates give lower bounds; real latency includes processing and queuing.

Exercises

Synthesis

Physical limits shape cloud architecture and resilience.

Continue studying — chapter 03 of 50

← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →