Server vật lý và các giới hạn

Hi các bạn 👋. Mình là Hùng Anh.

Đây là bài thứ hai trong series Kubernetes Fundamentals. Ở bài trước, mình đã đi qua kernel, driver, và sandbox thực chất là gì. Lần này cùng mình phân tích xem 1 server vật lý thực sự trông như thế nào, và vì sao không thể cứ deploy mãi lên cùng 1 server nhé.

Bắt đầu thôi.

1. Các thành phần trong 1 server vật lý

1 server vật lý đơn giản là 1 máy tính thật — 1 chiếc máy đang nằm trong datacenter (hoặc với nhiều người trong chúng ta lúc này, 1 chiếc laptop hay 1 con VPS thuê ngoài đang tạm đóng vai trò đó). Mọi thứ nó chạy đều nằm trên đúng cái stack mình đã gặp ở bài trước:

• Hardware — CPU, RAM, ổ đĩa, card mạng — phần thực sự làm việc.
• Kernel — thứ duy nhất được phép nói chuyện trực tiếp với phần cứng.
• Driver — bộ phiên dịch của kernel cho từng loại phần cứng cụ thể.
• OS (hệ điều hành) — kernel cộng với mọi thứ đi kèm nó: shell, package manager, các service hệ thống — thành phần giúp máy thực sự dùng được.
• Application — thứ mình thực sự deploy lên và muốn nó chạy: 1 API, 1 background worker, tùy công việc là gì.

Mọi thành phần trong số đó, từ app bạn deploy cho tới ổ đĩa nó ghi vào, đều nằm trên đúng 1 kernel duy nhất, chạy trên đúng 1 bộ phần cứng duy nhất. Chính sự thật đơn giản đó là toàn bộ giới hạn mà bài này nói tới.

2. Các giới hạn của server vật lý

Giả sử bạn cần deploy 1 web application. Cách đơn giản nhất: thuê hoặc mua 1 máy vật lý, cài OS, deploy app lên đó. Cách này chạy tốt — trong 1 thời gian.

• Phần lớn máy đó nằm không. Các khảo sát về server x86 thông thường cho thấy CPU trung bình chỉ dùng khoảng 10-15%. 85-90% còn lại là tài nguyên bạn đã trả tiền nhưng gần như không dùng tới. Cũng không thể cho ai mượn: chỉ có đúng 1 kernel ở đây, chạy đúng 1 workload, không có gì khác để nhường phần tài nguyên đang nằm không đó.
• 1 máy, 1 môi trường. Giả sử app thứ hai cần 1 môi trường khác — 1 phiên bản OS khác, hoặc 1 thư viện xung đột với phiên bản mà app đầu tiên đang dùng. Bạn không thể chỉ đơn giản thả nó lên cùng 1 kernel: kernel đó đang chạy đúng 1 phiên bản OS cụ thể rồi, không thể vừa chạy phiên bản đó cho app đầu tiên, vừa chạy 1 phiên bản khác cho app thứ hai cùng lúc. Lựa chọn duy nhất là thêm 1 máy vật lý khác.
• Scale rất chậm. Traffic tăng đột biến, cần thêm tài nguyên? Mua, lắp, đấu dây thêm 1 máy vật lý mất từ vài ngày đến vài tuần — không phải vài phút như 1 đợt traffic tăng thực tế cần.
• Mọi thứ trên đó chết cùng nhau. 1 máy, 1 điểm lỗi duy nhất. Nếu phần cứng hỏng, mọi app đang chạy trên đó đều sập cùng lúc.

Đến đây có câu hỏi được đặt ra: liệu có cách nào để 1 phần cứng vật lý duy nhất chạy được nhiều môi trường cô lập khác nhau cùng lúc — và thực sự tận dụng được 85% đang nằm không kia, thay vì để nó lãng phí?

Đó chính xác là ý tưởng đằng sau máy ảo (virtual machine - VM). Cách nó giải quyết bài toán này như nào sẽ là chủ đề của bài tiếp theo.

3. Tổng kết

1 server vật lý tương đương 1 kernel, gắn thẳng vào 1 bộ phần cứng, chạy đúng 1 OS đã cài lên nó. Đơn giản, nhưng có giới hạn rất thật: phần lớn tài nguyên nằm không mà không chia sẻ được, chỉ chạy được 1 OS/môi trường tại 1 thời điểm, và scale nghĩa là phải mua, lắp thêm phần cứng thật.

Giờ thì thư giãn một chút và sang bài tiếp về chủ đề Virtual Machine. Cùng mình xem nó giải quyết bài toán trên như nào và những nhược điểm của nó là gì nhé.

Happy reading! 🍵

Tài liệu tham khảo

1. The history of virtualization and its mark on data center management - TechTarget
2. What is Server Utilization Rate? A Guide to Data Center Efficiency - Hyperview