⏱️ 6 giờ
📐 Design Project
🖥️ 200 VMs
🏭 Enterprise
🎓 Mục Tiêu Project
Sinh viên thiết kế HOÀN CHỈNH hệ thống backup cho công ty thực tế VinaTech Corp — bao gồm infrastructure diagram, tính toán storage, thiết kế jobs, DR strategy, runbook và budget. Đây là project tích hợp kiến thức toàn khóa.
Scenario: VinaTech Corp
Công ty VinaTech Corp — Yêu Cầu Backup Infrastructure:
├─ Văn phòng chính (HỒ CHÍ MINH):
│ ├─ 150 VMs (VMware vSphere 8.0 U2)
│ ├─ 3 ESXi hosts × 512GB RAM = 1,536GB total RAM
│ ├─ Storage: Pure Storage FlashArray //C — 50TB NVMe
│ └─ Internet uplink: 1Gbps (Viettel Enterprise)
│
├─ Chi nhánh Hà Nội:
│ ├─ 30 VMs (VMware vSphere 7.0 U3)
│ ├─ 1 ESXi host, 256GB RAM, 20TB SAS storage
│ └─ WAN link → HCM: 100Mbps MPLS (Viettel)
│
└─ Chi nhánh Đà Nẵng:
├─ 20 VMs (Microsoft Hyper-V Server 2022)
├─ 1 Hyper-V host, 128GB RAM, 10TB SAS storage
└─ WAN link → HCM: 50Mbps MPLS (VNPT)
SLA / RPO-RTO Requirements:
├─ Database servers (20 VMs, avg 200GB): RPO 1h, RTO 15 min
├─ App servers (80 VMs, avg 80GB): RPO 4h, RTO 1h
├─ Dev/Test VMs (100 VMs, avg 50GB): RPO 24h, RTO 4h
└─ Budget ceiling: $80,000/năm (hardware + license + bandwidth)
Phân Tích SLA — Ánh Xạ Sang Veeam Features
| Tier | VMs | RPO | RTO | Veeam Solution | Recovery Method |
|---|---|---|---|---|---|
| Database | 20 | 1 giờ | 15 phút | VM Replication (RPO 15min) + CDP | Failover Replica → HN |
| App Server | 80 | 4 giờ | 1 giờ | Backup job 4h interval + SOBR | Instant VM Recovery |
| Dev/Test | 100 | 24 giờ | 4 giờ | Nightly backup + local repo | Traditional Restore |
Deliverable 1: Infrastructure Diagram
Sinh viên vẽ (hoặc hoàn thiện) ASCII diagram dưới đây — thêm IP range, bandwidth, storage capacity vào từng ô trống [____].
╔═══════════════════════════════════════════════════════════════════════════════════╗ ║ VINATECH CORP — VEEAM BACKUP TOPOLOGY ║ ╠════════════════════════╦══════════════════════╦══════════════════════════════════╣ ║ HCM (CHÍNH) ║ HÀ NỘI ║ ĐÀ NẴNG ║ ║ ║ ║ ║ ║ ┌──────────────────┐ ║ ┌────────────────┐ ║ ┌────────────────────────────┐ ║ ║ │ VBR Server │ ║ │ VBR Proxy │ ║ │ VBR Agent (Hyper-V) │ ║ ║ │ 192.168.[__].[__]│ ║ │ 192.168.[__].[_│ ║ │ 192.168.[__].[__] │ ║ ║ └────────┬─────────┘ ║ └───────┬────────┘ ║ └────────────┬───────────────┘ ║ ║ │ ║ │ ║ │ ║ ║ ┌────────▼─────────┐ ║ ┌───────▼────────┐ ║ ┌────────────▼───────────────┐ ║ ║ │ Proxy × [__] │ ║ │ ESXi Host │ ║ │ Hyper-V Host │ ║ ║ │ [__] cores each │ ║ │ 256GB RAM │ ║ │ 128GB RAM │ ║ ║ │ ESXi × 3 hosts │ ║ │ 30 VMs │ ║ │ 20 VMs │ ║ ║ │ 150 VMs │ ║ └───────┬────────┘ ║ └────────────┬───────────────┘ ║ ║ └────────┬─────────┘ ║ │ ║ │ ║ ║ │ ║ ┌───────▼────────┐ ║ ┌────────────▼───────────────┐ ║ ║ ┌────────▼─────────┐ ║ │ Local Repo │ ║ │ Local Repo │ ║ ║ │ SOBR Repo │ ║ │ [____] TB │ ║ │ [____] TB │ ║ ║ │ Extent 1: [__]TB │ ║ └────────────────┘ ║ └────────────────────────────┘ ║ ║ │ Extent 2: [__]TB │ ║ ║ ║ ║ │ WAN Acc (src) │ ║ ║ ║ ║ └────────┬─────────┘ ╠══════════════════════╩══════════════════════════════════╣ ║ │ ║ WAN LINKS ║ ╠═══════════╪════════════║ HCM ↔ HN: 100Mbps MPLS (Viettel) ║ ║ CLOUD │ ║ HCM ↔ DN: 50Mbps MPLS (VNPT) ║ ║ ┌────────▼─────────┐ ╚══════════════════════════════════════════════════════════╣ ║ │ Object Storage │ ║ ║ │ Azure / AWS S3 │ ← Archive tier: copies > [__] days ║ ║ │ Capacity: [__]TB │ ║ ║ └──────────────────┘ ║ ╚═══════════════════════════════════════════════════════════════════════════════════╝
Điền các giá trị [____] dựa trên tính toán ở Deliverable 2, 4.
Deliverable 2: Storage Sizing Calculation
Worksheet Tính Toán Storage — HCM Site
Thông số đầu vào:
DB daily change: 5%
App daily change: 2%
Dev daily change: 1%
Compression ratio: 2×
STORAGE SIZING — HCM (150 VMs):
┌─ DB Servers (20 VMs × 200GB avg):
│ Full backup size = 20 × 200GB = 4,000 GB
│ Daily incremental = 4,000 × 5% = 200 GB/day
│ 30-day retention = 4,000 + (200 × 30) = 10,000 GB ≈ 9.8 TB
│
├─ App Servers (80 VMs × 80GB avg):
│ Full backup size = 80 × 80GB = 6,400 GB
│ Daily incremental = 6,400 × 2% = 128 GB/day
│ 30-day retention = 6,400 + (128 × 30) = 10,240 GB ≈ 10.0 TB
│
└─ Dev/Test (50 VMs × 50GB avg): ← SINH VIÊN TÍNH
Full backup size = 50 × 50GB = [____] GB
Daily incremental = [____] × 1% = [____] GB/day
30-day retention = [____] + ([____] × 30) = [____] GB ≈ [__] TB
──────────────────────────────────────────────────────────
TỔNG HCM (raw):
DB: 9.8 TB
App: 10.0 TB
Dev: [____] TB
─────────────
Total raw: ≈ [____] TB ← sinh viên tính
Với compression 2×: ≈ [____] TB ← chia đôi
Add 20% overhead: ≈ [____] TB ← recommended provision
──────────────────────────────────────────────────────────
HÀ NỘI (30 VMs):
Ước tính: 30 VMs × 80GB avg × 30 ngày + 2% daily change
= [____] TB (sinh viên tính)
ĐÀ NẴNG (20 VMs):
= [____] TB (sinh viên tính)
Deliverable 3: Backup Job Design
Thiết kế 6+ backup jobs để cover toàn bộ 200 VMs. Điền vào bảng mẫu dưới đây, giải thích scheduling conflicts nếu có.
| Job Name | VMs / Site | Repository | Schedule | Retention | Mode | Notes |
|---|---|---|---|---|---|---|
| DB-Critical-HCM | 20 DB VMs / HCM | SOBR-Tier1-HCM | Every 1h (22:00-06:00 full) | 14 days | Reverse Inc + CDP | Replica ke HN song song |
| App-Prod-HCM | 80 App VMs / HCM | SOBR-Tier2-HCM | Every 4h | 30 days | Forever Forward Inc | Chia 2 sub-jobs tránh đụng |
| Dev-Test-HCM | 50 Dev VMs / HCM | Repo-Dev-HCM | Daily 03:00 | 7 days | Forever Forward Inc | Low priority, storage tier 2 |
| All-VMs-Hanoi | 30 VMs / HN | Repo-Local-HN | Daily 01:00 | 14 days | Forward Inc | Backup copy → HCM SOBR |
| All-VMs-Danang | 20 VMs / DN | Repo-Local-DN | Daily 02:00 | 14 days | Agent-based | Hyper-V agent, WAN throttle |
| BCopy-to-Cloud | DB + App VMs | Azure Blob SOBR | Weekly Sun 04:00 | 90 days | Backup Copy Job | Immutable 30 days |
Scheduling Conflicts cần xử lý: DB-Critical-HCM chạy every 1h sẽ đụng với App-Prod-HCM. Giải pháp: chia App-Prod-HCM thành 2 groups (40+40 VMs), stagger giờ chạy cách nhau 2h để tránh resource contention trên proxy.
Deliverable 4: Proxy Sizing
PROXY SIZING FORMULA:
1 proxy core ≈ 200 GB/giờ throughput
TÍNH TOÁN HCM:
Total daily backup data:
DB: 200 GB/day incremental + 4,000 GB weekly full (÷7) ≈ 771 GB/day
App: 128 GB/day incremental + 6,400 GB weekly full (÷7) ≈ 1,043 GB/day
Dev: 50 GB/day incremental + 2,500 GB weekly full (÷7) ≈ 407 GB/day
─────────────────────────────────────────────────────────
Total per day: ≈ 2,221 GB/day
Backup window: 6 giờ (22:00 – 04:00)
Required throughput: 2,221 GB ÷ 6h = 370 GB/h
Required proxy cores: 370 GB/h ÷ 200 GB/core = 1.85 → round up = 2 cores (min)
Add 50% buffer for peak + retries: = 3 cores needed
RECOMMENDATION:
Option A: 1 proxy × 4-core VM (simple, single point of failure)
Option B: 2 proxies × 4-core VM each (HA, recommended) ← CHỌN NÀY
Option C: 4 proxies × 2-core (high parallelism, more VMs simultaneous)
RESULT: 2 × Windows VM proxy, 4 cores + 8GB RAM each
+ 1 Linux hot-add proxy trên ESXi cluster (không qua network)
Bài tập sinh viên: Tính số proxy cho HN (30 VMs, 2h backup window) và ĐN (20 VMs, Hyper-V agent mode, 50Mbps WAN). Gợi ý: WAN bandwidth thường là bottleneck thay vì proxy cores.
Deliverable 5: DR Strategy
DB Servers (20 VMs)
- ✅ VM Replication → HN site
- ✅ RPO: 15 phút (CDP)
- ✅ RTO: <1 phút failover
- ✅ WAN Accelerator enabled
- ✅ Failover plan: auto
App Servers (80 VMs)
- ✅ Backup → HCM SOBR (primary)
- ✅ Backup Copy → Azure Blob
- ✅ Instant Recovery nếu VM fail
- ✅ Azure: immutable 30 days
- ✅ RTO: <1h Instant Recovery
Dev/Test (100 VMs)
- ⚠️ Local backup only (HCM)
- ⚠️ Không có offsite copy
- ⚠️ RTO: 4h traditional restore
- ℹ️ Acceptable theo SLA
- ℹ️ Dev có thể rebuild from code
DR TOPOLOGY: HCM (Production) HÀ NỘI (DR Site) ┌─────────────────────────┐ ┌─────────────────────────┐ │ DB-01 … DB-20 (live) │──────▶│ DB-01-Replica … (off) │ Replication 15min │ App-01 … App-80 (live) │ │ (no replica for App) │ │ Dev-01 … Dev-100 (live) │ └─────────────────────────┘ │ │ │ SOBR (primary repo) │ CLOUD (Azure) │ Extent 1: 10TB NVMe │──────▶ Backup Copy (weekly) │ Extent 2: 8TB SAS │ Immutable 30 days │ Cloud Tier: Azure │ Archive 90 days └─────────────────────────┘
Deliverable 6: DR Runbook
Scenario: HCM Datacenter mất điện hoàn toàn (Major Disaster)
Sinh viên hoàn thiện runbook 10 bước dưới đây (điền vào [SINH VIÊN ĐIỀN]):
-
01
Xác nhận disaster [T+0]: Nhận alert từ monitoring (Veeam ONE / PagerDuty). Xác nhận HCM unreachable qua ping + call NOC. Kích hoạt incident response.
-
02
Notify stakeholders [T+5min]: [SINH VIÊN ĐIỀN — ai cần được thông báo, kênh nào, template message]
-
03
Failover DB servers [T+15min]: Login Veeam console tại HN → Replicas → chọn tất cả DB replicas → Failover → Planned Failover. DB online tại HN.
-
04
Update DNS / Load Balancer [T+20min]: [SINH VIÊN ĐIỀN — DNS records cần đổi gì, TTL đã set sẵn bao nhiêu?]
-
05
Restore App servers từ Azure [T+30min]: Kết nối Azure Blob → Veeam Backup Console → Restore latest point cho 20 critical App VMs trước. Dùng Instant Recovery.
-
06
Verify App functionality [T+60min]: [SINH VIÊN ĐIỀN — test cases cụ thể: login, transaction, API call]
-
07
Restore remaining App VMs [T+2h]: Tiếp tục restore 60 App VMs còn lại theo priority. Traditional restore — chấp nhận RTO 4h theo SLA.
-
08
Document data loss [T+2h]: [SINH VIÊN ĐIỀN — RPO actual vs RPO SLA, tính delta data loss]
-
09
Rebuild HCM khi datacenter phục hồi: [SINH VIÊN ĐIỀN — failback procedure, sync data từ HN về HCM]
-
10
Post-incident review [T+72h]: Họp post-mortem. Cập nhật runbook. Gửi RCA report cho management. Update DR test schedule.
Deliverable 7: Budget Breakdown
| Hạng Mục | Loại | Số lượng | Đơn giá (USD) | Thành tiền | Ghi chú |
|---|---|---|---|---|---|
| Veeam Universal License | Software | 200 instances | $200/inst/yr | $40,000 | VUL covers VMware + Hyper-V |
| Veeam ONE | Software | 1 | $3,000/yr | $3,000 | Monitoring & reporting |
| Proxy Servers (HCM) | Hardware | 2 servers | $3,000 each | $6,000 | 4-core VM, one-time |
| NAS Repository HCM | Hardware | 20TB usable | $500/TB | $10,000 | SOBR extents, one-time |
| Azure Blob Storage | Cloud | 10TB/mo | $200/mo | $2,400/yr | Archive tier, recurring |
| WAN Bandwidth (MPLS) | Network | 2 links | $8,000/yr each | $16,000 | HCM↔HN + HCM↔DN |
| TỔNG CỘNG (năm đầu) | $77,400 | Dưới budget $80K ✓ | |||
ROI Calculation — Giá trị Downtime
Cost of 1h downtime (VinaTech)
$50,000
(revenue loss + SLA penalty)
Expected downtime without DR
8h/yr
= $400,000 potential loss
Backup investment
$77,400
ROI: 417% (payback 3 months)
Bảng Chấm Điểm (Grading Rubric)
| Deliverable | Điểm tối đa | Tiêu chí đạt điểm tối đa |
|---|---|---|
| Infrastructure Diagram | 20% | Đầy đủ components, IP/bandwidth/storage labels, 3 sites, cloud tier |
| Storage Calculation | 20% | Tính đúng công thức, số liệu khớp, giải thích compression ratio |
| Backup Job Design | 15% | ≥6 jobs, cover 200 VMs, scheduling hợp lý, no conflicts |
| Proxy Sizing | 10% | Công thức đúng, đề xuất N proxies với M cores có cơ sở |
| DR Strategy | 15% | Phân tier hợp lý, đáp ứng RPO/RTO SLA, topology diagram |
| DR Runbook | 10% | 10 steps đầy đủ, thực tế, có timeline, assign responsible team |
| Budget Breakdown | 10% | Đủ hạng mục, tổng ≤ $80K, ROI calculation có logic |
| TỔNG | 100% |
Sample Solution (Key Numbers)
Storage
- HCM raw total: ~28 TB
- With 2× compression: ~14 TB
- Provision (20% overhead): ~17 TB
- HN: ~6 TB, ĐN: ~4 TB
Proxies
- HCM: 4 × 4-core proxies
- (16 total cores = 3,200 GB/h capacity)
- HN: 1 × 2-core proxy
- ĐN: Agent-based (no dedicated proxy)
License
- VUL 200 instances: ~$40,000/yr
- Covers VMware + Hyper-V + Agent
- 1 VUL instance = 1 VM or 1 server
- Total budget: ~$77,400/yr ✓