Advanced Computer Architecture

Chapter 11
Cloud and Data-Center Architecture

Post Graduate Program in Computer Science Engineering
Advanced Computer Architecture   •   Post Graduate

Cloud and Data-Center Architecture

Introduction

Cloud computing and data-center architecture have transformed computer systems from individually owned machines into large-scale, programmable pools of computation, storage, and networking. At postgraduate level, the subject is not merely a study of virtual machines or server rooms. It concerns the architecture of a distributed system whose performance, reliability, energy use, security, and economics emerge from interactions among processors, memory hierarchies, networks, storage systems, virtualization layers, orchestration software, and operating policies.

A modern cloud data center is therefore a computer at building scale. Its design extends classical computer-architecture questions—parallelism, locality, communication cost, fault tolerance, and resource management—from a single processor to millions of cores and devices. The central architectural challenge is to provide the illusion of a dependable, elastic computer while operating over hardware that is heterogeneous, shared, geographically distributed, and subject to failure.

Learning Objectives

After studying this chapter, a student should be able to:

  1. Explain the architectural layers and service models of cloud computing.
  2. Analyze the roles of servers, memory, networks, storage, virtualization, and orchestration in a data center.
  3. Apply performance, availability, capacity, and energy models to cloud systems.
  4. Compare virtual machines, containers, serverless execution, and specialized accelerators.
  5. Design an architecture for a fault-tolerant and efficient cloud application.
  6. Evaluate security, governance, sustainability, and research challenges in cloud data centers.

1. Foundations and Architectural Evolution

Traditional enterprise computing used dedicated servers, storage arrays, and manually configured networks. Utilization was often low because capacity was provisioned for peak demand. Cloud computing introduced resource pooling, on-demand provisioning, measured usage, and multi-tenancy. These properties are enabled by data centers containing large numbers of commodity and specialized machines connected by high-speed networks.

The evolution may be understood in four stages:

  • Centralized mainframes: computation was concentrated in one highly controlled system.
  • Client–server systems: applications were divided between clients and shared servers.
  • Clusters and grids: independent computers were coordinated for parallel or high-throughput work.
  • Cloud data centers: virtualized and programmable pools provide elastic services through APIs.

The cloud is not a replacement for architecture; it is an architecture whose abstraction boundary is higher. A user sees a virtual CPU, a volume, or an API endpoint, while the provider manages physical processors, memory, switching fabrics, power distribution, cooling, and failures.

Essential terminology

  • Data center: A facility containing computing, storage, networking, power, cooling, and management infrastructure.
  • Cluster: A group of interconnected computers coordinated to execute workloads.
  • Host: A physical machine that runs virtual machines or containers.
  • Tenant: An organization or user sharing cloud infrastructure.
  • Elasticity: The ability to increase or decrease allocated resources in response to demand.
  • Multitenancy: Concurrent sharing of infrastructure by independently administered users.
  • Hypervisor: Software or firmware that creates and manages virtual machines.
  • Control plane: Components that schedule, configure, and monitor resources.
  • Data plane: Components that carry user computation, storage traffic, and packets.
  • Availability zone: An isolated failure domain within a cloud region.

2. Cloud Service and Deployment Models

The familiar service models describe responsibility boundaries rather than specific technologies.

ModelProvider commonly managesCustomer commonly managesTypical use
Infrastructure as a Service (IaaS)Physical infrastructure and hypervisorGuest OS, runtime, applications, dataCustom enterprise systems
Platform as a Service (PaaS)Infrastructure, OS, runtime, scaling platformApplication code and dataManaged application deployment
Software as a Service (SaaS)Nearly the complete service stackConfiguration and user dataBusiness applications
Function or serverless serviceInfrastructure, runtime, schedulingEvent handlers and policiesEvent-driven computation

Deployment may be public, private, community-based, or hybrid. The important architectural distinction is the location of trust, operational control, and failure domains. A private cloud may offer greater control but does not automatically provide better security or utilization. A public cloud provides scale and a broad service portfolio but introduces dependency on provider interfaces, pricing, regional availability, and legal jurisdiction.

3. The Data Center as a Layered Computer

A useful architecture separates the system into layers:

  1. Facility layer: utility power, generators, uninterruptible power supplies, cooling, fire protection, and physical security.
  2. Rack and server layer: processors, accelerators, memory, local storage, power supplies, and management controllers.
  3. Network layer: top-of-rack switches, aggregation, spine–leaf fabrics, routers, load balancers, and software-defined networking.
  4. Virtualization layer: hypervisors, virtual switches, virtual storage, and device mediation.
  5. Resource-management layer: schedulers, cluster managers, autoscalers, service discovery, and policy engines.
  6. Application layer: databases, analytics, web services, artificial-intelligence workloads, and user applications.
Layered cloud data-center architecture Applications and managed services Control plane: scheduling, orchestration, monitoring Virtualization: VMs, containers, virtual networks Data plane: servers, storage, switches, accelerators Facility: power, cooling, physical security
Layered cloud data-center architecture
Figure: Layered cloud data-center architecture

Figure: A cloud data center viewed as a vertically integrated computer system.

The layers are not independent. A scheduling decision can change network congestion; a cooling constraint can limit processor frequency; a storage-replication policy can affect inter-rack bandwidth. Consequently, cloud architecture requires cross-layer reasoning.

4. Compute Architecture and Heterogeneity

Data-center servers commonly contain multicore CPUs, large memory systems, local nonvolatile storage, and network interfaces. Workloads may also use GPUs, tensor-processing units, field-programmable gate arrays, or smart network devices. Heterogeneity improves efficiency when software is mapped to a suitable device, but it complicates scheduling, programming, portability, and capacity planning.

CPU and memory considerations

Performance depends on more than clock frequency. Important factors include instruction-level parallelism, cache locality, memory bandwidth, synchronization overhead, NUMA placement, and virtualization overhead. In a non-uniform memory access (NUMA) server, access time depends on the memory socket containing the requested data. A scheduler that places a thread on one socket while its data resides on another may incur additional latency and consume inter-socket bandwidth.

A first-order execution model is:

Ttotal = Tcompute + Tmemory + Tcommunication + TI/O + Toverhead

Here, each term is a time in seconds. The model is additive only as an approximation when activities do not substantially overlap. If computation and communication overlap, the effective time may instead be closer to the maximum of the overlapping components. The model is useful for identifying bottlenecks, not for predicting every microarchitectural detail.

For a parallel workload, Amdahl’s law gives a bound on speedup:

S(N) = 1 / (s + (1 − s)/N)

where S(N) is speedup on N processors and s is the fraction that remains serial. The assumptions are a fixed workload, identical processor speed, negligible resource contention, and no additional parallel overhead. For s = 0.1 and N = 8, the idealized speedup is 1/(0.1+0.9/8) ≈ 4.71, not eight. In cloud systems, scheduling, synchronization, network delays, and noisy neighbors usually reduce the observed value further.

Accelerators

Accelerators are valuable when a workload has regular parallelism and sufficient arithmetic intensity. They may be ineffective for branch-heavy, latency-sensitive, or communication-dominated tasks. A complete design must account for data-transfer cost between host memory and accelerator memory, device sharing, compiler support, and failure recovery.

5. Virtualization and Resource Isolation

A virtual machine presents virtual processors, memory, disks, and network interfaces to a guest operating system. Hardware-assisted virtualization allows privileged operations to be controlled efficiently, while techniques such as extended page tables reduce address-translation overhead. Virtual machines provide strong isolation and permit different operating systems to coexist, but they consume more memory and boot more slowly than containers.

Containers isolate processes using operating-system mechanisms such as namespaces and control groups. They are lightweight and well suited to microservices, but the host kernel is shared; therefore, kernel vulnerabilities and configuration errors can affect isolation. A container is not intrinsically a security boundary equivalent to a virtual machine.

Important virtualization issues include:

  • Oversubscription: assigning more virtual resources than physically available, relying on differing demand patterns.
  • Noisy neighbors: interference caused by co-located tenants competing for cache, memory bandwidth, storage, or network capacity.
  • Live migration: moving a running VM, usually by copying memory while it continues execution. Migration requires bandwidth and may cause a pause during final state transfer.
  • Device virtualization: sharing or assigning physical devices through mediated access or pass-through.
  • Resource accounting: measuring actual usage for scheduling, service-level objectives, and billing.

Isolation must be evaluated across CPU time, cache occupancy, memory bandwidth, I/O queues, network paths, and side channels—not only virtual CPU allocation.

6. Network Architecture

Data-center networks must provide high aggregate bandwidth, predictable latency, scalability, and rapid failure recovery. A common topology is the leaf–spine fabric. Servers attach to leaf switches, and every leaf connects to multiple spine switches. Equal-cost multipath routing distributes flows across available paths.

Network performance is governed by latency, bandwidth, serialization delay, queueing, and protocol processing. A simple transfer approximation is:

Ttransfer ≈ L + D/B

where L is fixed latency in seconds, D is data size in bits, and B is effective bandwidth in bits per second. This approximation ignores queueing, retransmissions, protocol headers, and contention. For a 64 MiB transfer over an effective 10 Gbit/s path with 0.1 ms fixed latency, using 64 MiB = 536,870,912 bits, the serialization time is approximately 53.69 ms, so the idealized total is about 53.79 ms.

Software-defined networking separates policy from packet forwarding. The control plane can express virtual networks, security groups, routing policies, and traffic engineering, while programmable data-plane devices execute forwarding at line rate. This separation improves flexibility but makes controller reliability, state consistency, and failure handling important architectural concerns.

7. Storage Architecture and Data Management

Cloud storage is commonly classified as:

  • Block storage: presents virtual disks with low-level read/write semantics; useful for databases and file systems.
  • File storage: provides shared hierarchical access through file protocols.
  • Object storage: stores immutable or versioned objects addressed by keys and metadata; it scales well for large unstructured datasets.

Storage systems trade consistency, durability, latency, capacity, and cost. Replication stores multiple copies, while erasure coding represents data using fragments and parity. For a replication factor r, raw capacity required for logical data D is approximately rD, before metadata and operational overhead. This is simple but wasteful for cold data. Erasure coding can reduce overhead but requires encoding, decoding, and more complex recovery.

Durability and availability are distinct. Durability concerns whether data is lost; availability concerns whether it can be accessed when requested. If independent components each have availability Ai, the availability of a series system that requires all components is:

Aseries = ∏ Ai

For parallel redundant components where the service works if at least one of n components works, assuming independent failures:

Aparallel = 1 − ∏(1 − Ai)

Independence is often an unrealistic assumption because a power, software, or regional failure can affect several components simultaneously. Correlated failures must therefore be modeled through failure domains and fault-injection testing.

8. Scheduling, Orchestration, and Elasticity

The scheduler maps tasks or services to resources under constraints such as CPU, memory, accelerators, affinity, locality, deadlines, cost, and regulatory placement. Common strategies include bin packing, fair sharing, priority scheduling, queue-based scheduling, and topology-aware placement.

Orchestrators maintain a desired state. If a service is declared to require ten replicas, the control plane observes the actual state and creates or removes instances until the desired state is approached. This reconciliation model supports recovery from crashes and machine replacement.

Autoscaling may be reactive, predictive, or hybrid. A basic utilization signal is:

u = λ / μ

where λ is the average arrival rate and μ is the average service rate, both in requests per second. For a stable single-server queue, u < 1 is necessary in the long run. As utilization approaches one, queueing delay can increase sharply; therefore, operating permanently near 100% utilization is usually incompatible with strict latency objectives.

A useful capacity-planning workflow is:

  1. Measure demand by time, region, tenant, and workload type.
  2. Identify the bottleneck resource rather than assuming CPU is limiting.
  3. Reserve failure and burst capacity.
  4. Test scaling delay and warm-up time.
  5. Validate performance under contention and partial failure.
  6. Reassess cost, energy, and service-level objectives.

9. Reliability, Availability, and Disaster Recovery

Failures in cloud data centers include disk faults, server crashes, switch failures, software defects, configuration errors, power interruptions, cooling events, and human mistakes. Reliability engineering therefore uses redundancy, failure isolation, replication, health checks, retries, circuit breakers, immutable deployment artifacts, and tested recovery procedures.

Availability is often summarized as:

Availability = Uptime / (Uptime + Downtime)

The quantities must use the same time unit and measurement period. If a service has 99.9% availability over a 30-day month, its permitted downtime is approximately 0.001 × 30 × 24 × 60 = 43.2 minutes, ignoring exclusions and measurement rules. A service-level objective (SLO) is an engineering target; a service-level agreement (SLA) is a contractual commitment, often with defined remedies.

Disaster recovery requires recovery point objective (RPO) and recovery time objective (RTO). RPO specifies the maximum acceptable data loss measured in time; RTO specifies the target time to restore service. Backups are not sufficient unless restoration is periodically tested. A geographically separate replica may improve resilience, but it introduces replication lag, cost, legal issues, and consistency decisions.

10. Energy, Cooling, and Sustainable Architecture

Data-center energy is consumed by computation, memory, storage, networking, cooling, power conversion, and lighting. Power usage effectiveness is defined as:

PUE = Total facility power / IT equipment power

Both terms are average power or energy measured over the same interval, so PUE is dimensionless and normally at least 1. A lower value indicates that a smaller fraction of facility energy is overhead, but PUE alone does not indicate how much useful work is performed.

More informative measures include energy per request, performance per watt, carbon intensity, water consumption, and embodied carbon. Architectural techniques include server consolidation, workload shifting to regions with lower-carbon electricity, liquid cooling for dense accelerators, power capping, thermal-aware scheduling, and hardware life extension. These decisions must consider latency, data sovereignty, reliability, and rebound effects: cheaper computation may stimulate additional demand.

11. Security, Governance, and Ethical Considerations

Cloud security follows a shared-responsibility model. Providers protect facilities and core infrastructure, while customers remain responsible for identity, configuration, data, and application security according to the service model. Frequent failures include excessive privileges, exposed storage, weak secrets management, insecure interfaces, unpatched images, and insufficient logging.

A defense-in-depth architecture includes:

  • strong identity, multifactor authentication, and least privilege;
  • network segmentation and workload identity;
  • encryption in transit and at rest, with managed key rotation;
  • secure image provenance and software supply-chain verification;
  • continuous configuration assessment;
  • tamper-resistant logs and incident response;
  • backup isolation and recovery testing.

Governance must address data classification, retention, auditability, cross-border transfer, accessibility, algorithmic accountability, and vendor exit. Multi-tenancy also raises side-channel concerns involving cache timing, speculative execution, memory deduplication, and shared accelerators. Security controls should be selected according to threat models rather than adopted as unexamined checklists.

12. Applied Case: Illustrative Multi-Region Retail Platform

Background

Consider an illustrative online retailer whose traffic varies by more than an order of magnitude during promotional events. The platform includes a product catalog, shopping cart, payment service, inventory database, recommendation engine, and analytics pipeline.

Problem

A single-region deployment experiences slow responses during bursts. The database is difficult to scale, deployment errors cause outages, and the company cannot clearly distinguish application failures from network or storage failures.

Analysis

The workload contains different architectural classes. Catalog reads are numerous and cacheable. Cart operations require stronger consistency for individual users. Payment operations require strict auditability and idempotence. Recommendations and analytics are compute-intensive but can tolerate delay. A single undifferentiated cluster would waste resources and create conflicting performance requirements.

Approach

The company adopts a multi-zone architecture within two regions. Stateless web services run in containers behind load balancers. A distributed cache serves catalog data. Transactional records use a replicated database with explicit consistency policies. Payment requests carry idempotency keys so that retries do not create duplicate charges. Events are placed on a durable queue and processed asynchronously for recommendations and analytics. The scheduler uses separate pools for general CPU services and accelerator-enabled recommendation jobs.

Observability is organized around service-level indicators: request latency, error rate, queue age, database saturation, cache hit ratio, and replication lag. Autoscaling uses both request rate and queue depth. Capacity is reserved for zone loss and promotional bursts. Backups are restored in a separate environment as part of scheduled exercises.

Outcome

The architecture isolates failure domains and allows each workload to scale according to its own bottleneck. Asynchronous processing prevents analytics from blocking checkout. The design does not eliminate failure: regional failover remains operationally complex, distributed consistency requires careful product decisions, and duplicate or delayed events remain possible. However, explicit contracts, observability, and tested recovery make these risks manageable.

Learning points

  1. Architecture should follow workload semantics rather than organizational ownership.
  2. Replication improves availability only when failure independence and recovery behavior are understood.
  3. Autoscaling cannot compensate for poor data modeling or unbounded queue growth.
  4. Idempotence, observability, and recovery testing are architectural features.
  5. Multi-region operation creates governance and consistency costs that must be justified by business requirements.

13. Contemporary Developments and Research Directions

Several trends are reshaping cloud architecture:

  • Disaggregated infrastructure: compute, memory, and storage are pooled and connected through high-speed fabrics, potentially improving utilization but increasing access latency and protocol complexity.
  • Confidential computing: trusted execution environments protect data during processing, although they introduce attestation, performance, and side-channel questions.
  • Composable and chiplet-based systems: modular packaging enables specialized accelerators and memory interfaces, but software must manage greater heterogeneity.
  • Edge–cloud continuum: latency-sensitive processing moves closer to users while the cloud supplies centralized coordination and large-scale analytics.
  • AI-oriented infrastructure: accelerators, high-bandwidth memory, collective communication, and model-parallel scheduling are increasingly central. Energy and cooling constraints are major design variables.
  • Carbon-aware orchestration: schedulers incorporate electricity-carbon signals alongside latency and cost.
  • Serverless and WebAssembly: finer-grained isolation and rapid startup can reduce operational burden, but execution limits, observability, and state management remain challenging.

Research questions include how to provide predictable performance under multitenancy, how to quantify correlated failures, how to schedule heterogeneous resources fairly, and how to measure useful work per unit of energy and carbon. Reproducible experimentation requires workload traces, clearly defined baselines, controlled fault injection, and reporting of variance rather than only average performance.

Design Best Practices

  1. Define workload objectives, SLOs, RPO, RTO, compliance constraints, and cost limits before selecting technologies.
  2. Separate control-plane and data-plane failure analysis.
  3. Use explicit failure domains: host, rack, zone, region, and provider.
  4. Measure bottlenecks across CPU, memory, storage, network, and queues.
  5. Prefer automation, immutable artifacts, versioned configuration, and policy as code.
  6. Treat observability and recovery testing as first-class design requirements.
  7. Minimize privileges and encrypt sensitive data with managed key governance.
  8. Evaluate total cost and environmental impact, not only hourly compute price.
  9. Avoid assuming that containers, replication, or multiple regions automatically provide security or availability.
  10. Revisit architecture as workload patterns, hardware, regulations, and energy conditions change.

Chapter Summary

Cloud and data-center architecture extends computer architecture to a distributed, shared, and geographically organized system. Its layers include facilities, servers, networks, virtualization, control planes, and applications. Effective designs account for processor and memory locality, heterogeneous accelerators, network transfer time, storage semantics, scheduling, elasticity, and failure domains.

Virtual machines provide strong operating-system isolation, while containers offer lightweight deployment with a shared-kernel risk. Leaf–spine networks and software-defined control support scalable connectivity. Block, file, and object storage serve different access patterns and consistency requirements. Availability, transfer time, parallel speedup, utilization, and PUE provide useful analytical models, but their assumptions must be made explicit.

Reliable cloud systems combine redundancy with observability, tested recovery, idempotent operations, and carefully defined SLOs. Security requires identity controls, segmentation, encryption, supply-chain protection, and governance across the shared-responsibility boundary. Sustainable architecture considers energy, carbon, water, cooling, and useful work—not PUE alone. Emerging systems emphasize disaggregation, confidential computing, edge processing, AI accelerators, and carbon-aware scheduling. The central lesson is that cloud architecture is a cross-layer optimization problem involving performance, availability, security, cost, sustainability, and organizational objectives.

Key Terms

Cloud computing: On-demand delivery of pooled computing resources through network-accessible services.

Data center: Facility containing computing, storage, networking, power, cooling, and management systems.

Multitenancy: Sharing infrastructure among independently administered users or organizations.

Elasticity: Dynamic expansion or contraction of allocated resources.

IaaS: Cloud service model providing virtualized infrastructure resources.

PaaS: Managed platform for deploying applications without managing the underlying infrastructure.

SaaS: Complete software service operated by a provider.

Hypervisor: Software or firmware that manages virtual machines.

Container: Isolated process environment sharing the host operating-system kernel.

NUMA: Architecture in which memory-access cost depends on processor and memory location.

Accelerator: Specialized hardware designed for particular computation patterns.

Leaf–spine network: Data-center topology connecting leaf switches to a set of spine switches.

Object storage: Key-addressed storage of objects and metadata, generally optimized for scale.

Control plane: System responsible for configuration, scheduling, and policy.

Data plane: System that executes workloads and carries user traffic.

SLO: Target level of service performance or reliability.

RPO: Maximum acceptable period of data loss after a disruption.

RTO: Target time for restoring service after a disruption.

PUE: Ratio of total facility energy to IT equipment energy.

Noisy neighbor: Co-located workload whose resource competition interferes with another workload.

Review Questions

Short Answer Questions

  1. Distinguish between the control plane and the data plane in a cloud data center.
  2. Why is a container not automatically equivalent to a virtual machine as a security boundary?
  3. Define elasticity and explain why it is different from simple scalability.
  4. What are RPO and RTO, and how do they influence disaster-recovery design?
  5. State two limitations of using PUE as the only sustainability metric.

Long Answer Questions

  1. Explain the layered architecture of a cloud data center and discuss cross-layer interactions.
  2. Compare virtual machines, containers, and serverless execution with respect to isolation, startup time, portability, and operational control.
  3. Discuss storage choices among block, file, and object storage for transactional, shared-file, and archival workloads.
  4. Explain how scheduling, autoscaling, and workload placement affect performance in a heterogeneous cluster.
  5. Analyze the security and governance implications of multitenancy and the shared-responsibility model.

Analytical / Application Questions

  1. A service has 10% serial execution and runs on 8 processors. Use Amdahl’s law to calculate the ideal speedup and explain why a real cloud deployment is likely to achieve less.
  2. Design a failure-resilient architecture for a payment service that must survive loss of one availability zone. State your consistency, idempotence, replication, monitoring, and recovery choices.
  3. A workload transfers 128 MiB over a 5 Gbit/s link with 0.5 ms fixed latency. Estimate the ideal transfer time, state the assumptions, and identify practical factors that may increase it.

Multiple Choice Questions with Answers

Question 1

Which component primarily belongs to the control plane of a cloud data center?

A. A packet forwarding ASIC

B. A workload scheduler

C. A solid-state drive

D. A CPU arithmetic unit

Correct Answer: B. A workload scheduler

Question 2

What is the main isolation limitation of ordinary containers compared with virtual machines?

A. Containers cannot run network services

B. Containers require a separate physical server

C. Containers commonly share the host operating-system kernel

D. Containers cannot be restarted automatically

Correct Answer: C. Containers commonly share the host operating-system kernel

Question 3

Using Amdahl’s law, what is the ideal speedup for a workload with serial fraction 0.1 on 8 processors?

A. 2.86

B. 4.71

C. 7.20

D. 8.00

Correct Answer: B. 4.71

Question 4

A 64 MiB transfer uses an effective 10 Gbit/s link and has 0.1 ms fixed latency. Ignoring overhead and queueing, which time is closest?

A. 0.54 ms

B. 5.48 ms

C. 53.8 ms

D. 538 ms

Correct Answer: C. 53.8 ms

Question 5

Which storage model is generally addressed by keys and optimized for large-scale unstructured data?

A. Object storage

B. Register storage

C. Instruction cache

D. NUMA memory

Correct Answer: A. Object storage

Question 6

What does an RPO specify?

A. The maximum acceptable data-loss interval

B. The number of processors per host

C. The maximum network packet size

D. The target processor frequency

Correct Answer: A. The maximum acceptable data-loss interval

Question 7

If a facility consumes 1,200 kW and its IT equipment consumes 800 kW, what is its PUE?

A. 0.67

B. 1.00

C. 1.50

D. 2.00

Correct Answer: C. 1.50

Question 8

Why can operating a queueing system near 100% utilization be problematic?

A. It guarantees zero throughput

B. Queueing delay can increase sharply as utilization approaches one

C. It prevents all hardware failures

D. It eliminates the need for capacity planning

Correct Answer: B. Queueing delay can increase sharply as utilization approaches one

Question 9

What is the principal architectural advantage of a leaf–spine data-center network?

A. It eliminates all routing decisions

B. It provides multiple paths and scalable east–west connectivity

C. It requires only one switch for the entire facility

D. It prevents every form of congestion

Correct Answer: B. It provides multiple paths and scalable east–west connectivity

Question 10

Which practice best supports recovery from repeated payment-request retries?

A. Disabling logging

B. Using idempotency keys

C. Removing transaction identifiers

D. Allowing unrestricted duplicate submission

Correct Answer: B. Using idempotency keys

Advanced Computer Architecture
Chapter 11 of 11