SLA availability
scheduled = hours/day × days
NPTEL key: availability = 1 − down / (scheduled − down)
simple : availability = 1 − down / scheduled
SLA met if availability ≥ promised %
PYQ18 h/day × 30 days = 540 h, outages 6 + T, promise 98%: (6+T)/(534−T) ≤ 0.02 → T ≤ 4.59, so T = 5 or 6 breaks the SLA.
Failed requests allowed = requests × (1 − success%). 10,000 × 0.5% = 50.
Lecture 11 defines availability as 1 − downtime/uptime, which is the NPTEL form. Both formulas usually give the same option; if the options are close, use the NPTEL form.
Your 202699% of 12 h × 30 days = 3.6 h. 99.9% of 720 h = 0.72 h ≈ 43 min.
Cloud vs owning (Cloudonomics)
U = C / B (utility premium)
P = peak demand, A = average demand
own : B_T = P × B × T
cloud: C_T = U × B × A × T = ∫ C·D(t) dt
cloud cheaper ⇔ U < P / A
PYQP = 200, D(t) = 8t, B = 120, C = 150: own = 24,000T, cloud = ∫150·8t dt = 600T². Cloud cheaper when T < 40.
Hybrid is often best, and the key factor is the peak-to-average ratio. Utility pricing suits variable demand.
Your 2026Average 75, peak 225, U = 2.8: P/A = 3 > 2.8, so cloud is cheaper.
Demand, Cv and penalty
Cv = σ / |μ|
n independent demands → Cv shrinks by 1/√n
penalty ∝ ∫ |D(t) − R(t)| dt
- Flat demand: penalty 0, periodic provisioning works
- Linear demand: fixed-interval provisioning gives a constant penalty
- Exponential demand: fixed interval falls behind exponentially, so the penalty is exponential (not linear)
MapReduce and HDFS
blocks(file) = ceil(size / block size)
small files still take 1 block each
replicas = blocks × replication (default 3)
mappers ≈ number of input splits
PYQA 2019 question says 6 files make "24 blocks" with 64 MB blocks. It only works as 8 blocks × 3 replicas, so X ≤ 64 MB and Y ≤ 64 MB both fit.
Rating-count problems: map emits (key, 1) only for rows that match, reduce sums per key. Keys with zero matches don't appear.
Your 2026700 MB with 128 MB blocks → 6 blocks → 6 map tasks. The Partitioner picks each key's reducer; the Combiner is optional and may run 0, 1 or many times.
VM migration time
non-live: total time = downtime = M / B
use binary units: 1 GB = 2^30 B, 1 MB = 2^20 B
1024 GB / 16 MB/s = 65,536 s ≈ 18.2 h
64 GB / 8 MB/s = 8,192 s ≈ 2.3 h
PYQThe answer keys mark "18 h, 18 h" and "2 h, 2 h": pick the option where both numbers are equal and closest to M / B.
Live migration (pre-copy, post-copy) keeps downtime small. Pre-copy uses the most bandwidth.
Your 202632 GB at 16 MB/s = 32 × 1024 ÷ 16 = 2,048 s ≈ 34 min.
Small but frequent
OpenStack vCPUs = physical × overcommit
900 × 4.5 = 4,050; 640 × 5 = 3,200
(default CPU 16:1, RAM 1.5:1)
PUE = total facility power / IT power (ideal 1.0)
cache: address bits = tag + index + offset
set-assoc: tag = addr − log2(cache / ways)
Ports: 0–1023 well-known, 1024–49151 registered, 49152–65535 dynamic. IPv4 classes: A 1–126, B 128–191, C 192–223, D 224–239.