Bài 9 — Compute — VM (Virtual Machine) Basics

Mở đầu — vì sao bài này quan trọng

Nếu bạn hỏi mười kỹ sư DevOps rằng "dịch vụ nào bạn dùng đầu tiên khi bước chân lên cloud?", thì có lẽ chín người sẽ trả lời: Virtual Machine — máy ảo. Trước khi có container, trước khi có serverless, thì VM chính là đơn vị tính toán (compute) nền tảng của điện toán đám mây. Trên AWS nó tên là EC2, trên Google Cloud là Compute Engine, trên Azure là Virtual Machines, còn trên các nhà cung cấp Việt Nam như Viettel IDC hay FPT Cloud thì gọi đơn giản là "Cloud Server" hoặc "Cloud VPS".

Vì sao VM vẫn cực kỳ quan trọng dù bây giờ ai cũng nói về Kubernetes và Lambda? Bởi vì bên dưới gần như mọi thứ, cuối cùng vẫn có một máy ảo đang chạy. Cụm Kubernetes của bạn chạy trên các VM (node). Hàm serverless của bạn thực thi trong một môi trường được ảo hóa. Khi bạn cần chạy một ứng dụng cũ (legacy) không thể đóng gói thành container, hay cần toàn quyền kiểm soát hệ điều hành, thì VM là lựa chọn duy nhất hợp lý.

Hiểu VM một cách thấu đáo — hypervisor là gì, ranh giới trách nhiệm giữa bạn và nhà cung cấp nằm ở đâu, cách chọn loại instance cho đúng, cách trả tiền sao cho rẻ — sẽ giúp bạn tiết kiệm hàng chục triệu đồng mỗi tháng và tránh những sự cố ngớ ngẩn. Đây là bài học nền tảng mà mọi kiến thức compute sau này đều dựa vào.

Khái niệm cốt lõi

VM là gì và hypervisor hoạt động ra sao

Virtual Machine (máy ảo) là một hệ điều hành (OS) hoàn chỉnh chạy như một "máy tính giả lập" bên trong một máy chủ vật lý (physical host). Điều làm cho việc này khả thi là một lớp phần mềm đặc biệt gọi là hypervisor.

Hãy hình dung một máy chủ vật lý trong trung tâm dữ liệu (data center) của AWS: nó có thể có 128 nhân CPU, 512 GB RAM. Sẽ rất lãng phí nếu chỉ có một khách hàng dùng nguyên cả cái máy đó. Hypervisor giải quyết điều này: nó chia nhỏ tài nguyên phần cứng của host thành nhiều máy ảo độc lập, mỗi máy ảo tưởng như mình đang sở hữu phần cứng riêng, dù thực chất chúng đang chia sẻ chung một host.

Có hai loại hypervisor:

• Type 1 (bare-metal): chạy trực tiếp trên phần cứng, không cần OS nền. Đây là loại mà các cloud provider dùng vì hiệu năng cao và bảo mật tốt. Ví dụ: KVM (nền tảng của phần lớn hạ tầng Google Cloud và nhiều nhà cung cấp), Xen (AWS dùng nhiều năm trước khi chuyển sang Nitro dựa trên KVM), Hyper-V (Microsoft Azure).
• Type 2 (hosted): chạy như một ứng dụng trên OS thông thường, ví dụ VirtualBox hay VMware Workstation trên laptop của bạn. Loại này dùng cho phát triển, thử nghiệm, không dùng cho production quy mô lớn.

Điểm mấu chốt bạn cần nhớ: cloud provider quản lý hypervisor và phần cứng; bạn quản lý từ hệ điều hành trở lên. Đây chính là ranh giới trách nhiệm.

Mô hình trách nhiệm chia sẻ (Shared Responsibility)

Khi bạn thuê một VM, hãy vẽ ra ranh giới rất rõ ràng trong đầu:

Nhà cung cấp lo:

• Phần cứng vật lý (CPU, RAM, ổ đĩa, mạng)
• Hypervisor và lớp ảo hóa
• Điện, làm mát, an ninh vật lý của data center
• Bảo trì phần cứng khi hỏng

Bạn lo:

• Hệ điều hành: cập nhật bản vá (patch), nâng cấp kernel
• Cấu hình bảo mật OS: firewall nội bộ, tài khoản người dùng, SSH key
• Các phần mềm, runtime, ứng dụng bạn cài đặt
• Dữ liệu của bạn

Đây là điểm rất nhiều người mới mắc sai lầm. Họ nghĩ "cloud thì AWS lo hết bảo mật rồi". Sai. Nếu bạn để lộ cổng SSH ra Internet với mật khẩu yếu, bị hack, thì đó là lỗi của bạn, không phải AWS. Nhà cung cấp bảo vệ cái nhà, bạn phải khóa cửa phòng của mình.

Các thành phần cấu thành một VM

Khi khởi tạo một VM, bạn sẽ luôn phải quyết định các thành phần sau:

1. Instance type / machine type (loại máy) — quyết định số vCPU và dung lượng RAM. Các nhà cung cấp phân loại theo mục đích sử dụng:

• General purpose (cân bằng CPU/RAM): AWS t3, m6i; GCP e2, n2. Dùng cho web server, ứng dụng thông thường.
• Compute optimized (nhiều CPU): AWS c6i; GCP c2. Dùng cho xử lý tính toán nặng, encode video, game server.
• Memory optimized (nhiều RAM): AWS r6i, x2; GCP m2. Dùng cho database lớn, cache in-memory.
• GPU/Accelerated: AWS p4, g5. Dùng cho AI/ML, render đồ họa.

2. vCPU (virtual CPU) — một vCPU thường tương ứng với một luồng (thread) của CPU vật lý, không phải một nhân đầy đủ. Đây là lý do 2 vCPU cloud không nhanh bằng 2 nhân trên máy tính để bàn của bạn.

3. Image / OS — bản mẫu hệ điều hành để khởi động. Trên AWS gọi là AMI (Amazon Machine Image), GCP gọi là Image. Bạn chọn Ubuntu, Amazon Linux, Windows Server, v.v. Bạn cũng có thể tạo image tùy chỉnh đã cài sẵn phần mềm để nhân bản (clone) nhanh.

4. Storage (ổ đĩa gắn kèm) — VM cần ổ đĩa để lưu OS và dữ liệu. Trên cloud, ổ này thường là block storage (như AWS EBS). Bài này chỉ nhắc qua vì storage là chủ đề riêng ở các bài sau — điều bạn cần biết là VM và ổ đĩa của nó là hai thứ tách rời nhau.

5. Network — VM nằm trong một mạng ảo (VPC), có địa chỉ IP nội bộ (private) và có thể có IP công khai (public). Firewall ở tầng cloud gọi là Security Group (AWS) hay Firewall Rules (GCP).

Cách trả tiền cho VM — điều ảnh hưởng trực tiếp đến túi tiền

Đây là phần mà hiểu đúng sẽ giúp bạn tiết kiệm rất nhiều:

• On-demand: trả theo giờ/giây sử dụng, bật lúc nào trả tiền lúc đó, tắt là ngừng tính. Linh hoạt nhất nhưng đắt nhất. Phù hợp workload không đoán trước.
• Reserved Instances / Committed Use: cam kết dùng 1–3 năm, đổi lại giảm giá 30–70%. Phù hợp cho server chạy liên tục 24/7.
• Spot Instances / Preemptible: dùng phần công suất dư thừa của nhà cung cấp, rẻ tới 70–90%, nhưng có thể bị thu hồi bất cứ lúc nào với thông báo ngắn. Tuyệt vời cho batch job, CI/CD runner, xử lý dữ liệu có thể chịu gián đoạn.

Một mẹo quan trọng: on-demand tính tiền khi VM đang chạy (running), không phải khi đã tắt (stopped). Nhưng ổ đĩa gắn kèm vẫn tính tiền dù VM tắt. Nhiều bạn tưởng "tắt máy là hết tiền" rồi cuối tháng vẫn thấy hóa đơn từ ổ đĩa.

Tình huống thực tế

Tình huống 1: Startup fintech ở TP.HCM chọn sai instance type

Một startup fintech giả định tên PayFast ở Quận 1 vừa gọi vốn vòng seed, thuê một kỹ sư backend làm luôn cả DevOps. Anh này khởi chạy API xử lý giao dịch trên một VM AWS m5.2xlarge (8 vCPU, 32 GB RAM) vì "nghe nói to là chắc chắn". Hóa đơn tháng đầu: khoảng 280 USD chỉ cho riêng con VM này, chạy 24/7.

Sau khi xem CloudWatch, họ phát hiện CPU trung bình chỉ dùng 8%, RAM dùng 5 GB. API của họ chủ yếu chờ database, chứ không tính toán nặng. Họ chuyển sang t3.large (2 vCPU, 8 GB RAM, loại burstable — có thể "bùng" hiệu năng khi cần), giá còn khoảng 60 USD/tháng. Rồi họ mua thêm Reserved Instance 1 năm, giảm còn khoảng 38 USD/tháng.

Bài học: Đừng chọn instance theo cảm tính "to cho chắc". Bắt đầu nhỏ, đo bằng monitoring, rồi phóng to (scale up) nếu cần. Với workload chờ I/O nhiều, loại burstable như t3/t4g rẻ và hợp lý hơn hẳn.

Tình huống 2: Studio game Đông Nam Á dùng Spot Instance để render

Một studio game giả định ở Singapore, PixelForge, cần render các cảnh 3D cho trailer. Công việc này chạy hàng loạt (batch), có thể chia thành nghìn task nhỏ, và nếu một task bị gián đoạn thì chỉ cần chạy lại task đó — không mất mát gì nghiêm trọng.

Nếu dùng on-demand GPU instance (g4dn), họ tốn khoảng 0.526 USD/giờ mỗi máy. Với 40 máy chạy 3 ngày liên tục, chi phí lên tới hơn 1.500 USD. Họ chuyển sang Spot Instances, giá chỉ còn khoảng 0.15 USD/giờ — tiết kiệm gần 70%, còn khoảng 430 USD. Đổi lại, đôi khi AWS thu hồi vài máy, nhưng hệ thống render của họ được thiết kế để tự đưa task bị gián đoạn về hàng đợi và giao cho máy khác.

Bài học: Spot/Preemptible là "vũ khí bí mật" để tiết kiệm cực lớn — nhưng chỉ dùng cho workload chịu được gián đoạn (stateless, batch, có thể retry). Tuyệt đối đừng chạy database chính trên Spot.

Tình huống 3: Doanh nghiệp Việt chọn Cloud VN vì lý do tuân thủ dữ liệu

Một ngân hàng số giả định VietDigiBank cần triển khai hệ thống nội bộ nhưng theo yêu cầu của Ngân hàng Nhà nước và Nghị định về bảo vệ dữ liệu, dữ liệu nhạy cảm của khách hàng cần lưu trong lãnh thổ Việt Nam với độ trễ thấp tới người dùng trong nước. Thay vì đặt VM ở region Singapore của AWS (độ trễ khoảng 30–60ms và dữ liệu ra khỏi Việt Nam), họ chọn Cloud Server của Viettel IDC và FPT Cloud đặt tại data center ở Hà Nội và TP.HCM.

Về mặt kỹ thuật, VM ở đây cũng chạy trên hypervisor (thường là KVM/VMware), mô hình trách nhiệm chia sẻ y hệt. Khác biệt nằm ở vị trí data center (data residency), hỗ trợ tiếng Việt, xuất hóa đơn VNĐ và tuân thủ quy định pháp lý trong nước.

Bài học: VM về bản chất kỹ thuật là như nhau ở mọi nhà cung cấp. Nhưng yếu tố data residency, độ trễ tới người dùng và tuân thủ pháp lý đôi khi quan trọng hơn cả giá và tính năng. Nhà cung cấp Việt Nam là lựa chọn nghiêm túc chứ không phải "hàng thay thế cấp thấp".

Hướng dẫn từng bước

Hãy đi qua quy trình khởi tạo và vận hành một VM cơ bản (lấy AWS EC2 làm ví dụ, các nhà cung cấp khác tương tự về ý niệm):

Bước 1 — Xác định nhu cầu. Ứng dụng của bạn cần bao nhiêu CPU, RAM? Chạy liên tục hay theo đợt? Chịu được gián đoạn không? Trả lời ba câu này trước khi bấm nút nào.

Bước 2 — Chọn image (OS). Chọn AMI phù hợp, ví dụ Ubuntu 22.04 LTS. Ưu tiên bản LTS (hỗ trợ dài hạn) cho production.

Bước 3 — Chọn instance type. Bắt đầu với loại general purpose nhỏ như t3.small hoặc t3.medium. Bạn luôn có thể đổi sau bằng cách dừng máy rồi chọn lại loại.

Bước 4 — Tạo và tải SSH key pair. Đây là "chìa khóa" để đăng nhập vào máy. Tải file .pem về và giữ an toàn — mất là không lấy lại được. Không dùng mật khẩu cho SSH; dùng key.

Bước 5 — Cấu hình Security Group (firewall). Mở đúng cổng cần thiết: cổng 22 (SSH) chỉ cho IP của bạn (không mở 0.0.0.0/0), cổng 80/443 nếu là web server. Quy tắc vàng: mở càng ít cổng càng tốt.

Bước 6 — Chọn storage. Gắn một ổ đĩa (ví dụ 20 GB SSD gp3). Nhớ bật xóa ổ đĩa khi hủy máy nếu không muốn tốn tiền lưu trữ thừa.

Bước 7 — Khởi chạy và kết nối. Bấm launch, chờ máy chuyển sang trạng thái running, rồi kết nối: ssh -i key.pem ubuntu@<public-ip>.

Bước 8 — Cập nhật OS ngay lập tức. Việc đầu tiên trên máy mới: sudo apt update && sudo apt upgrade -y. Đừng để máy chạy với phần mềm lỗ hổng.

Bước 9 — Đặt monitoring và tự động tắt/backup. Bật CloudWatch để theo dõi CPU/RAM. Cân nhắc lịch tự tắt máy dev ngoài giờ làm việc để tiết kiệm.

Lỗi thường gặp & mẹo

Lỗi 1: Để VM chạy 24/7 dù chỉ dùng ban ngày. Máy dev, staging thường chỉ cần chạy giờ hành chính. Đặt lịch tự tắt buổi tối và cuối tuần có thể cắt tới 65% chi phí. Nhiều đội tiết kiệm được hàng triệu đồng mỗi tháng chỉ nhờ điều này.

Lỗi 2: Mở cổng SSH (22) cho cả Internet. Bot quét cổng 22 liên tục 24/7. Chỉ mở cho dải IP của bạn, hoặc dùng bastion host / SSM Session Manager để truy cập mà không cần mở cổng.

Lỗi 3: Nhầm "stop" với "terminate". Stop là tắt máy (dừng tính tiền compute nhưng vẫn giữ dữ liệu và vẫn trả tiền ổ đĩa). Terminate là hủy hoàn toàn — mất máy và có thể mất luôn dữ liệu nếu ổ đĩa đặt chế độ xóa. Đọc kỹ trước khi bấm.

Lỗi 4: Không tách dữ liệu khỏi VM. Đừng coi VM là nơi lưu trữ dữ liệu quý. VM có thể chết bất cứ lúc nào (nhất là Spot). Dữ liệu quan trọng nên nằm trên ổ đĩa riêng hoặc dịch vụ lưu trữ/database được backup.

Lỗi 5: Chọn quá to ngay từ đầu (over-provisioning). Như tình huống PayFast — luôn bắt đầu nhỏ, đo, rồi tăng.

Mẹo: Dùng chip ARM (AWS Graviton, các instance đuôi g như t4g, m7g) khi được — thường rẻ hơn 20% và tiết kiệm điện hơn, phù hợp phần lớn ứng dụng web/backend hiện đại.

Mẹo: Với môi trường production, đừng cài đặt máy bằng tay rồi quên. Hãy tạo image tùy chỉnh hoặc dùng script khởi tạo (user data) để mọi VM đều nhất quán và tái tạo được.

Bài tập thực hành

• Tính chi phí: Tra bảng giá của một nhà cung cấp bất kỳ (AWS, GCP, hoặc Viettel IDC). Tính chi phí on-demand hàng tháng cho một VM 2 vCPU / 4 GB RAM chạy 24/7. Sau đó tính lại nếu chỉ chạy 10 giờ/ngày, 5 ngày/tuần. So sánh phần trăm tiết kiệm.

• Khởi tạo thực tế: Nếu có tài khoản cloud (nhiều nhà cung cấp có gói miễn phí/dùng thử), hãy khởi tạo một VM Ubuntu nhỏ nhất, kết nối SSH bằng key, chạy sudo apt update, cài Nginx, và mở cổng 80 để xem trang mặc định qua trình duyệt. Sau đó terminate máy để tránh phát sinh phí.

• Phân tích quyết định: Với ba workload sau, hãy chọn mô hình trả tiền (on-demand / reserved / spot) và giải thích: (a) database chính của công ty; (b) một job xử lý ảnh hàng loạt chạy mỗi đêm; (c) web server production chạy liên tục nhiều năm.

• Vẽ ranh giới trách nhiệm: Liệt kê 5 việc bảo mật thuộc trách nhiệm của bạn và 3 việc thuộc nhà cung cấp khi dùng VM.

Tóm tắt

• VM là một hệ điều hành hoàn chỉnh chạy trong hypervisor (KVM, Xen, Hyper-V) trên một máy chủ vật lý được chia sẻ. Đây là đơn vị compute nền tảng của cloud.
• Ranh giới trách nhiệm: nhà cung cấp lo phần cứng và hypervisor; bạn lo từ hệ điều hành trở lên — vá lỗi, bảo mật, phần mềm, dữ liệu.
• Khi tạo VM, bạn chọn: instance type (CPU/RAM theo mục đích), image (OS), storage, và network. Bắt đầu nhỏ, đo bằng monitoring rồi mới scale.
• Mô hình trả tiền quyết định chi phí: on-demand (linh hoạt, đắt), reserved (cam kết, rẻ hơn cho workload 24/7), spot (rẻ nhất nhưng có thể bị thu hồi — chỉ dùng cho workload chịu gián đoạn).
• Các lỗi tốn tiền phổ biến: để máy chạy 24/7 không cần thiết, over-provisioning, mở SSH cho cả Internet, nhầm stop với terminate, và coi VM là nơi lưu dữ liệu quý.
• Nhà cung cấp Việt Nam (Viettel IDC, FPT Cloud, VNG Cloud) cung cấp VM tương đương về kỹ thuật, và là lựa chọn nghiêm túc khi cần data residency, độ trễ thấp trong nước và tuân thủ pháp lý.

Nắm vững VM là bạn đã có nền móng cho mọi thứ phía trước — từ container, Kubernetes cho tới auto-scaling. Ở các bài tiếp theo, chúng ta sẽ xây dựng tiếp trên nền tảng compute này.