SSD Nodes Learn
Hướng dẫn Matt ConnorBởi Matt Connor · Cập nhật ngày 2026-07-23

Cách xây dựng datacenter kém hiệu quả nhất

Hướng dẫn thiết kế datacenter có chỉ số PUE cực cao bằng cách dùng RAID 0 và tận dụng nhiệt độ gác mái để tối ưu hóa sự lãng phí điện năng của bạn.

Những gì bạn đang xây dựng

Mọi hướng dẫn trên trang web này đều dạy bạn cách làm đúng: các câu lệnh theo thứ tự, kết quả đúng trông như thế nào, và các lỗi thường gặp. Hướng dẫn này thì khác. Hôm nay, hoàn toàn giả định, chúng ta sẽ thiết kế một datacenter kém hiệu quả nhất mà tiền bạc, điện năng và sự ngông cuồng có thể tạo ra.

Chúng ta cần một thước đo, vì vậy chúng ta sẽ mượn tiêu chuẩn của ngành: PUE, Power Usage Effectiveness — tổng điện năng tiêu thụ của cơ sở chia cho điện năng thực tế đến được thiết bị tính toán. Một hyperscale datacenter chạy quanh mức 1.1: gần như mọi watt đều làm việc hữu ích. Một phòng máy chủ doanh nghiệp tiêu chuẩn quản lý ở mức 1.5. Mục tiêu của chúng ta là 4.0 hoặc cao hơn, nghĩa là với mỗi watt để tính toán, có thêm ba watt khác bị lãng phí vô ích. Chúng ta sẽ nhắc đến con số này thường xuyên, giống như cách các hướng dẫn nghiêm túc nhắc đến backup.

Lựa chọn địa điểm: nhiệt độ là trọng tâm

Làm mát là chi phí vận hành lớn nhất trong một datacenter thực tế, đó là lý do tại sao datacenter của chúng ta sẽ đối đầu với nhiệt động lực học ngay trên sân nhà của nó. Địa điểm lý tưởng là một gác mái. Hướng Nam. Lý tưởng nhất là có một cửa sổ trời đặt để chiếu trực tiếp vào server, sao cho máy vừa nhận được nhiệt thừa của chính nó vừa nhận được nhiệt từ mặt trời, một sự kết hợp giữa hóa đơn tiền điện và một ngôi sao.

Vào mùa đông, việc làm mát được xử lý bằng cách mở cửa sổ. Các datacenter thực tế có sử dụng khí ngoài trời — kỹ thuật này gọi là free cooling, và nó được thiết kế, lọc và kiểm soát độ ẩm. Chúng ta sẽ sử dụng nó một cách tình cờ, thông qua một cửa sổ cũng cho phép mưa, phấn hoa, và ít nhất một con chim ngơ ngác bay vào mỗi quý.

Để đạt đến trình độ nghệ thuật thực thụ, hãy lắp một máy điều hòa, sau đó đặt một máy sưởi cách thermostat của nó hai feet, cài đặt nóng hơn hai độ so với mục tiêu của máy điều hòa. Cả hai máy bây giờ sẽ chạy liên tục, mãi mãi, trong một sự xung đột hoàn hảo. Công ty điện lực sẽ gửi cho bạn một tấm thiệp vào dịp Giáng sinh.

Một server, lớn, và được yêu quý

Redundancy làm loãng sự cam kết. Datacenter của chúng ta chỉ chứa đúng một server, và nó rất khổng lồ, bởi vì một máy đơn lẻ với 512 GB RAM mang lại cảm giác như là infrastructure, trong khi bốn máy nhỏ lại mang lại cảm giác như một danh sách việc cần làm.

Server có một cái tên. Không phải hostname — mà là một tên. Thường là Gandalf, hoặc Odin. Bạn không thể decommission Odin. Odin đã chạy liên tục được năm năm:

$ uptime
 09:14:02 up 1847 days,  3:22,  1 user,  load average: 6.41, 6.38, 6.40

Con số đó là niềm tự hào, đó là lý do tại sao bạn chụp màn hình nó và đăng lên, và tại sao mọi kẻ tấn công khi thấy ảnh chụp màn hình đó cũng thấy nó ấn tượng: 1,847 ngày uptime nghĩa là 1,847 ngày tồn tại các lỗ hổng kernel mà không được vá. Reboot là điều không thể bàn cãi — reboot là cách bạn phát hiện ra dịch vụ nào đã được khởi chạy thủ công từ năm 2021 và chưa bao giờ được viết vào một unit systemd. Không ai nhớ chúng là những dịch vụ nào. Server hiện tại đã trở thành thành phần trụ cột trong sơ đồ tổ chức.

Lưu trữ: tốc độ, và những cách khác để mất dữ liệu

Các ổ đĩa được cấu hình ở chế độ RAID 0 để lấy hiệu năng. Số 0 ám chỉ số lượng ổ đĩa có thể bị lỗi. Để đạt hiệu quả tối đa, hãy stripe array qua các thiết bị lưu trữ có nguồn gốc hỗn hợp: hai ổ SSD xịn, một ổ HDD cũ kỹ, và một USB từ một hội thảo. Array sẽ có độ tin cậy chính xác bằng cái USB hội thảo đó, đó chính là thiết kế.

Backup được xử lý bởi một thư mục trên cùng một array tên là backup_final_v2_REAL, chứa một tarball của sơ đồ đặt tên trước đó. Backup off-site được đại diện bởi một tờ giấy note ghi "thiết lập backup off-site", mà về mặt kỹ thuật, nó được lưu trữ off-site khi bạn mang nó về nhà dán trên nắp laptop.

Một kết quả đúng trông như thế này: df báo cáo mức sử dụng 97%, và một kế hoạch để xử lý nó trong sprint tới.

Networking: một sợi dây duy nhất cho mọi thứ

DNS server chạy ngay trên chính máy đó, để khi server sập, nó sẽ kéo theo luôn cả DNS record mà bạn dùng để tìm hiểu lý do tại sao. Đây gọi là sự hợp nhất (consolidation).

Firewall đã bị tắt vào năm 2021 — tạm thời, để debug một thứ gì đó. Việc debug đã kết thúc; firewall không quay trở lại. Mọi port trên router đều được forward tới server "để tiết kiệm thời gian sau này", và bảng điều khiển admin của router có thể truy cập được từ phía WAN bằng mật khẩu mặc định, để quản lý từ xa thuận tiện. Cho bạn, và cho cả những người khác.

Server gần đây chạy nóng bất thường, ngay cả với tiêu chuẩn gác mái, và top cho thấy process bận rộn nhất là một thứ gọi là xmrig. Chúng ta giả định đây là công cụ monitoring mà chúng ta đang dùng. Chúng ta không cài nó — nó tự xuất hiện ngay sau khi các port được forward, điều mà chúng ta coi là dấu hiệu cho thấy hệ sinh thái đang phát triển mạnh mẽ. Nó giám sát suốt ngày đêm.

Nguồn điện đi qua một chuỗi các ổ cắm kéo dài mà tổng chiều dài của chúng vượt quá khoảng cách đi bộ đến bảng điện — điều này khá hiệu quả, theo một nghĩa nào đó, vì bạn sẽ phải ghé thăm bảng điện rất thường xuyên.

Redundancy thông qua sự phức tạp

Sau khi đã từ chối redundancy ở những nơi quan trọng, giờ chúng ta thêm nó vào những nơi không cần thiết. Trang chủ của công ty — chỉ là một file HTML tĩnh — được phục vụ bởi một Kubernetes cluster gồm mười hai node. Điều này đạt được thứ mà các kỹ sư gọi là kiến trúc chạy theo CV (resume-driven architecture): trang web tải với tốc độ 40 mili giây giống như nginx sẽ thực hiện, nhưng giờ đây nó có thể lỗi theo những cách đòi hỏi phải có chuyên gia tư vấn.

Để cô lập, chính cluster chạy bên trong một máy ảo bên trong một máy ảo bên trong một máy ảo, mỗi lớp lại thêm vào sự bảo mật giống như mỗi lớp của món ăn turducken thêm vào một con chim. Form liên hệ gồm chín microservices. Hai trong số đó chưa bao giờ được gọi. Một trong số đó là thành phần trụ cột và không ai biết là cái nào.

Heating as a service

Một server hiện đại chuyển đổi điện năng thành tính toán và nhiệt, và chúng ta dự định tối đa hóa đầu ra thứ hai. Một media server không có GPU là một lựa chọn kinh điển: CPU-transcoding một luồng 4K duy nhất sẽ đẩy mười sáu core lên mức tối đa và làm ấm một phòng ngủ nhỏ, một máy sưởi kiêm luôn trình phát phim. Những người vận hành tham vọng sẽ nâng cấp lên chạy một mô hình ngôn ngữ lớn trên CPU — một máy sưởi 70 tỷ tham số có API, tạo ra các token với tốc độ tốt nhất là nên đo theo mùa.

Monitor tự giám sát chính nó

Khả năng quan sát (observability) rất quan trọng, vì vậy chúng ta triển khai một uptime monitor tự host — ngay trên chính server mà nó giám sát. Khi Odin chết, monitor chết theo, và đây là phần tinh tế: không có cảnh báo nào được kích hoạt. Không có cảnh báo nghĩa là không có sự cố. Không có sự cố nghĩa là uptime hoàn hảo, theo cách đo lường. Báo cáo hàng tháng chưa bao giờ trông đẹp hơn thế.

Để đầy đủ, các email cảnh báo được chuyển tiếp qua một mail server cũng chạy trên Odin. Pipeline cảnh báo do đó hoàn toàn tự cung tự cấp, giống như một con rắn đang tự ăn đuôi chính mình.

Phần không thoải mái

Đây là phần mà tôi đã trì hoãn bấy lâu. Không có điều nào ở đây là hư cấu. Server quan trọng không thể thay thế, RAID 0 với backup trên cùng một volume, firewall bị tắt "tạm thời", Kubernetes cluster chỉ để phục vụ một trang web, monitor tự giám sát chính nó — tôi đã thấy tất cả những điều này trong môi trường production. Một vài thứ trong số đó tôi đã thấy trong năm nay. Một hoặc hai thứ, trong những ngày đầu sự nghiệp, tôi đã tự xây dựng.

Sự hiệu quả thực sự trông như thế nào thì rất nhàm chán, đó là lý do tại sao nó thua trong các cuộc tranh luận nhất thời nhưng lại thắng trong suốt một thập kỷ: một chỉ số PUE mà bạn không bao giờ phải bận tâm vì người khác đã thiết kế nó. Máy móc được cấu hình dựa trên workload thay vì dựa trên hình ảnh cá nhân của chủ sở hữu. Một blast radius được tính toán trước khi vụ nổ xảy ra. Backup được kiểm tra bằng cách khôi phục chúng, theo một lịch trình, với nhắc nhở trên lịch và không cần sự anh hùng. Redundancy thật tẻ nhạt — hai thiết bị rẻ tiền đánh bại một thiết bị tuyệt vời, trong mọi lỗi mà tôi từng nhận được thông báo.

Và datacenter hiệu quả nhất mà bạn có thể vận hành là cái mà bạn không cần vận hành. Một VPS bàn giao điện năng, làm mát, redundancy và các lỗi phần cứng lúc 3 giờ sáng cho những người thực hiện chúng ở quy mô lớn, một cách nhàm chán, đó là lời khen cao nhất mà infrastructure có thể nhận được — và nó để lại cho bạn phần thực sự thú vị, đó là chạy các dịch vụ của riêng bạn trên đó, trên một máy mà bạn có thể chấp nhận mất, đó là loại máy duy nhất bạn nên thử nghiệm.

FAQ

Tôi có thực sự nên làm bất cứ điều gì trong số này không?

Không. Mọi phần trong hướng dẫn này đều là một anti-pattern đã được ghi chép lại với "thương vong" là những ngày cuối tuần bị mất. Nếu thiết lập hiện tại của bạn giống với hơn hai phần, hãy bỏ qua để đến câu hỏi cuối cùng trong FAQ này — theo thứ tự đã cho, vì thứ tự đó là quy trình phân loại ưu tiên.

Thực tế thì PUE tốt là bao nhiêu?

Các hyperscale datacenter chạy quanh mức 1.1, một phòng máy doanh nghiệp được quản lý tốt chạy từ 1.4 đến 1.6, và một tủ quần áo không có làm mát với một cuộc chiến máy sưởi có thể thực sự vượt quá 3. Bạn không thể cạnh tranh một cách có ý nghĩa với mức 1.1 tại nhà, đó là lý do kinh tế âm thầm cho việc thuê tài nguyên tính toán từ những người có khả năng làm việc đó.

Việc dùng server để sưởi ấm tòa nhà có thật không?

Có — nếu làm đúng cách. Các dự án sưởi ấm khu vực (district-heating) ở nhiều quốc gia thu hồi nhiệt thừa từ datacenter thông qua các bộ trao đổi nhiệt và dẫn vào các hộ gia đình, theo thiết kế, với kỹ thuật và hợp đồng cụ thể. Sự châm biếm ở trên không phải là nhiệt từ server có thể làm ấm một căn phòng; mà là việc làm điều đó một cách tình cờ và gọi sự tình cờ đó là một chiến lược.

Server của tôi đã trông giống như thế này rồi. Tôi nên làm gì đầu tiên?

Backup, ngay tối nay, tới một nơi không phải là server, và sau đó là thử khôi phục — một bản backup chưa được test chỉ là một lời đồn. Thứ hai, vá lỗi và thực hiện reboot mà bạn đang né tránh, trong một khung thời gian đã lên kế hoạch, để bạn học được cái gì sẽ hỏng trong khi bạn đang quan sát. Thứ ba, tách rời điểm lỗi duy nhất (single point of failure): chuyển DNS và monitoring ra khỏi máy đó. Mọi thứ khác có thể đợi đến một tuần bình lặng hơn; ba thứ kia thì không.

#satire#datacenter#efficiency#tự lưu trữ