Data Centers and Infrastructure as a Service

Lecture 2 of Cloud, Web & Mobile (Univ. Duisburg-Essen, Torben Weis): “Rechenzentren” + “Infrastructure as a Service”. Note: the source PDF was classified Mixed — slides that were pure images (figures of racks, containers, the provider landscape) came through only as captions.

1. Data-center requirements

RequirementContent
Kühlungenergy-intensive and expensive; no cooling ⇒ system shutdown
Stromversorgungchoose a region with cheap electricity; redundant energy infrastructure — “Transformatoren brennen gerne mal ab”
Netzanbindunggood connection to the Internet backbones
Personalideal: “Dark Datacenter” without permanent on-site staff
Sicherheitno unauthorized Zutritt/Zugriff

2. Organization: continent → cluster → rack → server

  • Data centers are distributed over all continents.
  • Räumliche Nähe reduces network cost; geographic location determines the legal framework (data protection in the EU vs. the USA).
  • A data center consists of clusters; each cluster has its own management that distributes tasks to individual machines (example of a cluster: one container — “Datacenter im Container”).
  • Clusters consist of racks; each rack has a common switch.
  • A rack consists of individual cheap servers.

The hierarchy matters because failure domains nest inside it: one switch per rack means one rack is a shared failure domain for every server in it.

3. Failure is the normal case

“Mindestens ein Server in jedem Rack ist stets kaputt.” — at least one server in each rack is always broken.

Two strategies, and the course argues for the second:

  • Expensive hardware helps etwas: hotswappable disks/memory/CPUs make broken hardware easy to replace; redundant power supplies and disks — but very expensive.
  • Kostengünstiger: standard PC hardware — very failure-prone, therefore:
    • Software must treat the failure case as the normal case → more complicated algorithms.
    • Intermediate results must be persisted regularly so a dying node does not lose hours of work.
    • Replication prevents data loss.

4. Replication placement

PlacementTrade-off
Across data centers (ideal)survives DC-level failures, but increases network cost
Within the same rack (worst case)fast communication, but the rack has multiple single points of failure: switch, network cable, power cable, cooling

Speed versus failure risk: machines in the same rack communicate quickly; machines in different data centers have high latency. Therefore the distribution of machines across racks, clusters, and data centers must be considered in the software configuration — there is no location transparency (software cannot pretend placement doesn’t matter).

Replication does not replace backups. Replication copies a mistake as faithfully as it copies data.

5. Physical security

AttackCountermeasure
Remote attack over the networkcryptography
Local attack inside the DC — theft of disksencrypted storage
Local attack — reprogramming of serverscontrol access to data centers: cameras, security guards, biometrics, …
Evaluating defective disks (including those being discarded)physical destruction of old disks

6. The IaaS market

  • AWS — the largest/best-known provider; the biggest business area of Amazon.
  • Rackspace — offers various technologies, including OpenStack.
  • Eucalyptus — open-source software offering AWS-compatible APIs.

7. Business model of IaaS

  • Renting infrastructure: virtuelle Server-Instanzen, a virtual private network (VPN), payment per use (CPU time, instances, storage, communication, …).
  • Usage is remote only: HTTP/HTML via a web browser (direct user interaction) or web services via HTTP + REST/SOAP — REST = Representational State Transfer.

Why customers buy IaaS

  • Fixed costs become variable costs — attractive for startups (less tied-up capital); idle time causes no cost.
  • Infrastructure scales with the business — fast adaptation to higher demand.
  • Operating one’s own data center is difficult (not a core competency).

Why providers sell IaaS

  • Cheap prices by avoiding idle time: the assumption is that individual customers’ peak loads distribute over the day (statistical multiplexing).
  • Renting out surplus capacity — Amazon is the canonical example.

8. Virtual servers

  • Installation of (almost) any operating system — mostly Linux, sometimes Windows.
  • Konfektionsgrößen (sizes), example Amazon EC2 m5d.large: 8 GiB memory, 2 vCPU (up to 3.1 GHz Intel Xeon Scalable), 75 GB NVMe SSD, I/O up to 10 Gbps network + 4.75 Gbps EBS.
  • “bis” = maximum at bursts, normally less — a credit-based system: credits accumulate while idle and are spent during bursts.
FamilyStrengthsUse case
Small / Medium / Large (standard)more of everything: RAM, CPU, storagegeneral workloads
High-CPUparticularly more computeCPU-bound tasks, e.g. simulations
High-Memoryabove-average RAMmemory-bound tasks, e.g. databases, caches
Acceleratedadditional coprocessors (GPU, Tensor, …)rendering, cryptanalysis, AI

9. Instance purchasing models (Frankfurt prices, 27.09.2023)

ModelPricePropertyFits
On-Demand$0.136/h — most expensivebilled per hour of compute, no cost when idlespiky, unpredictable load
Reserved$0.08/h + one-time annual paymentcheaper hourly ratethe base load that is always there
Spot$0.0416/h — cheapestinstances start when servers are idle; no guarantee when the computation happensinterruptible batch work

The exam-relevant logic: reserved for the baseline, on-demand for the variable part, spot for work that can wait or die — a pure cost-scenario question.

10. Public IP addresses and Elastic IP

  • Virtual servers have IP addresses; by default the customer cannot change them.
  • DNS problem: a virtual server crashes → thanks to IaaS a replacement is quick, but with a different IP address → DNS needs an update, which is slow because of DNS caching.
  • Solution: freely bindable public IP (e.g. Amazon Elastic IP): software binds the IP address to any virtual server instance, no DNS change is necessary, the provider reroutes packets internally.

11. Virtual Private Cloud (VPC)

  • VPCs allow full control over IP addresses: private addresses (10.x.x.x) and own address ranges.
  • Routing is freely configurable.
  • Setup of private servers plus a DMZ (DeMilitarized Zone): only servers in the DMZ can be reached from the Internet; all others are “protected” by the router.
  • Connection to the VPC via VPNs.
  • Consequence: users of a VPC cannot distinguish a server in the cloud from one in their own data center — the cloud becomes a private extension of the corporate network.

Exam hooks

  • Failure-domain question: “put both replicas in the same rack — what breaks you?” Answer with the rack-level SPOF list (switch, network cable, power cable, cooling) and with the latency-vs-safety trade-off.
  • “Replication ⇒ backup?” — No. Replication does not replace backups; both are needed.
  • Cheap hardware justification: standard PC hardware is cheaper than redundant enterprise hardware because software assumes failure — persist intermediate results, replicate, tolerate node loss.
  • Why not just buy servers? Fixed → variable cost, bounded loss, elasticity during hockey-stick growth.
  • Spot vs reserved vs on-demand: reason from the load profile and from “no guarantee when the computation happens”.
  • Elastic IP vs DNS: bind IP ⇒ no DNS propagation delay; provider reroutes internally.
  • DMZ purpose: expose only a defined set of hosts to the Internet; everything else is behind the router.
  • “Dark Datacenter”: the cost argument for minimal on-site personnel, not a security recommendation by itself.
  • Location transparency trap: the same feature can cost latency or resilience depending on placement — the software configuration must know the topology.
  • Energy/siting: cheap electricity + backbone proximity + legal jurisdiction are the three siting criteria; the jurisdiction one is the exam’s favorite (EU vs. USA data protection).

Sources