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
| Requirement | Content |
|---|---|
| Kühlung | energy-intensive and expensive; no cooling ⇒ system shutdown |
| Stromversorgung | choose a region with cheap electricity; redundant energy infrastructure — “Transformatoren brennen gerne mal ab” |
| Netzanbindung | good connection to the Internet backbones |
| Personal | ideal: “Dark Datacenter” without permanent on-site staff |
| Sicherheit | no 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
| Placement | Trade-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
| Attack | Countermeasure |
|---|---|
| Remote attack over the network | cryptography |
| Local attack inside the DC — theft of disks | encrypted storage |
| Local attack — reprogramming of servers | control 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.
| Family | Strengths | Use case |
|---|---|---|
| Small / Medium / Large (standard) | more of everything: RAM, CPU, storage | general workloads |
| High-CPU | particularly more compute | CPU-bound tasks, e.g. simulations |
| High-Memory | above-average RAM | memory-bound tasks, e.g. databases, caches |
| Accelerated | additional coprocessors (GPU, Tensor, …) | rendering, cryptanalysis, AI |
9. Instance purchasing models (Frankfurt prices, 27.09.2023)
| Model | Price | Property | Fits |
|---|---|---|---|
| On-Demand | $0.136/h — most expensive | billed per hour of compute, no cost when idle | spiky, unpredictable load |
| Reserved | $0.08/h + one-time annual payment | cheaper hourly rate | the base load that is always there |
| Spot | $0.0416/h — cheapest | instances start when servers are idle; no guarantee when the computation happens | interruptible 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
master-cs/raw/cloud-web-mobile/02_rechenzentren_iaas.md(converted from02_rechenzentren_iaas.pdf, 20 pages —PARTIAL: image-only slides have no text layer)- Course: Cloud, Web & Mobile · previous: Cloud Computing: History, Motivation & Terminology
- Cross-wiki: system design (replication, availability), distributed systems (failure models, replication placement)