Hướng dẫn xây datacenter kém hiệu quả nhất

Bạn đang xây dựng gì

Mọi hướng dẫn trên trang này đều chỉ cho bạn cách thực hiện đúng một việc: các lệnh theo đúng thứ tự, kết quả đúng trông như thế nào và các dạng lỗi có thể xảy ra. Hướng dẫn này thì khác. Hôm nay, hoàn toàn trên giả thuyết, 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ạo mạn có thể tạo ra.

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

Chọn địa điểm: nhiệt mới là mục tiêu

Làm mát là khoản chi phí vận hành lớn nhất trong một datacenter thực tế. Vì vậy, 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à gác mái. Hướng về phía nam. Tốt nhất là có một skylight được đặt sao cho ánh nắng chiếu trực tiếp vào server, để máy nhận cả nhiệt thải của chính nó lẫn nhiệt từ mặt trời — sự phối hợp giữa hóa đơn tiền điện của bạn và một ngôi sao.

Vào mùa đông, việc làm mát được thực hiện bằng cách mở cửa sổ. Datacenter thực sự cũng sử dụng không khí bên ngoài. Kỹ thuật này được gọi là free cooling và được thiết kế với hệ thống lọc, kiểm soát độ ẩm. Chúng ta sẽ vô tình sử dụng nó qua một cửa sổ cũng cho mưa, phấn hoa và ít nhất một con chim đang hoang mang bay vào mỗi quý.

Để đạt đến nghệ thuật đích thực, 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 máy điều hòa 2 feet, với mức cài đặt cao hơn mục tiêu của máy điều hòa 2 độ. Cả hai máy sẽ chạy liên tục, mãi mãi, trong sự bất đồng hoàn hảo. Công ty điện lực sẽ gửi thiệp cho bạn vào dịp Giáng sinh.

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

Dự phòng làm giảm mức độ gắn bó. Datacenter của chúng tôi chỉ có đúng một server, và nó rất lớn, vì một máy duy nhất với 512 GB RAM tạo cảm giác như hạ tầng, còn bốn máy nhỏ lại giống 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 cái tên. Thường là Gandalf hoặc Odin. Bạn không thể ngừng vận hành Odin. Odin đã hoạt động đượ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, nên bạn chụp màn hình rồi đăng lên, và mọi attacker nhìn thấy ảnh chụp 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 ai vá. Dù sao thì cũng không thể reboot, vì reboot là lúc bạn phát hiện dịch vụ nào được khởi động thủ công vào năm 2021 nhưng chưa từng được viết thành systemd unit. Không ai nhớ đó là những dịch vụ nào. Server giờ đã trở thành thành phần không thể thiếu trong sơ đồ tổ chức.

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

Các ổ đĩa được cấu hình ở RAID 0 để tăng hiệu năng. Số 0 chỉ số ổ đĩa có thể hỏng. Để đạt hiệu quả tối đa, hãy stripe array trên các thiết bị lưu trữ có nguồn gốc khác nhau: hai SSD đúng chuẩn, một ổ đĩa quay đã cũ và một USB stick từ một hội nghị. Array có độ tin cậy đúng bằng USB stick của hội nghị. Đó chính là thiết kế.

Backup được xử lý bằng một thư mục trên cùng array có tên backup_final_v2_REAL. Thư mục này chứa một tarball của naming scheme trước đó. Backup ngoài site được đại diện bằng một sticky note ghi "thiết lập backup ngoài site". Về mặt kỹ thuật, sticky note được lưu ngoài site khi bạn mang nó về nhà trên nắp laptop.

Kết quả đúng có dạng: df báo mức sử dụng 97% và có kế hoạch xử lý việc này trong sprint tiếp theo.

Mạng: một sợi dây duy nhất kết nối mọi thứ

DNS server chạy ngay trên máy chủ. Vì vậy, khi máy chủ ngừng hoạt động, DNS record dùng để tìm nguyên nhân cũng không còn. Đây được gọi là hợp nhất.

Firewall đã bị tắt vào năm 2021 để tạm thời gỡ lỗi một vấn đề. Việc gỡ lỗi đã kết thúc, nhưng firewall không được bật lại. Tất cả port trên router đều được chuyển tiếp đến máy chủ “để sau này đỡ mất thời gian”. Admin panel của router có thể truy cập từ phía WAN bằng factory password, nhằm thuận tiện cho việc quản trị từ xa. Không chỉ bạn làm vậy, những người khác cũng vậy.

Gần đây, máy chủ chạy nóng bất thường, ngay cả theo tiêu chuẩn của một căn gác mái. top cho thấy process bận nhất có tên là xmrig. Chúng tôi giả định đây là monitoring tool đang sử dụng. Chúng tôi không cài đặt nó. Nó tự xuất hiện ngay sau khi các port được chuyển tiếp. Chúng tôi xem đó là dấu hiệu hệ sinh thái đang phát triển tốt. Nó monitor liên tục cả ngày lẫn đêm.

Nguồn điện đi qua một chuỗi power strip dân dụng có tổng chiều dài lớn hơn quãng đường đi bộ đến breaker panel. Xét theo một nghĩa nào đó, cách này rất hiệu quả, vì bạn sẽ thường xuyên phải đến breaker panel.

Dư thừa do phức tạp

Sau khi từ chối dùng dự phòng ở những nơi quan trọng, giờ chúng ta lại thêm nó vào những nơi không cần. Trang chủ của công ty, chỉ gồm một tệp HTML tĩnh, được phục vụ bởi một Kubernetes cluster gồm 12 node. Cách này tạo ra thứ mà các kỹ sư gọi là kiến trúc phục vụ hồ sơ xin việc: trang vẫn tải trong 40 mili-giây, đúng bằng thời gian nginx cần để phân phối trang, nhưng giờ có thể gặp các lỗi cần đến consultant để xử lý.

Để cô lập, chính cluster này chạy bên trong một virtual machine nằm trong một virtual machine, nằm trong một virtual machine khác, mỗi lớp bổ sung thêm bảo mật giống như mỗi lớp của một món turducken bổ sung thêm một loại gia cầm. Form liên hệ gồm 9 microservice. 2 trong số đó chưa từng được gọi. Một service trong số đó đang giữ cho hệ thống hoạt động, nhưng không ai biết đó là service nào.

Sưởi ấm như một dịch vụ

Một server hiện đại chuyển điện năng thành năng lực tính toán và nhiệt, và mục tiêu của chúng ta là tối đa hóa đầu ra thứ hai. Media server không có GPU là cách kinh điển: CPU-transcoding một stream 4K duy nhất sẽ tải kín 16 core và làm ấm một phòng ngủ nhỏ, giống một máy sưởi có thể phát phim. Người vận hành tham vọng hơn sẽ chuyển sang chạy mô hình ngôn ngữ lớn trên CPU, một máy sưởi 70-billion-parameter có API, tạo token với tốc độ tốt nhất nên đo theo mùa.

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

Khả năng observability rất quan trọng, nên chúng ta triển khai một uptime monitor tự host trên chính server mà nó giám sát. Khi Odin ngừng hoạt động, monitor cũng ngừng theo, và đây là phần “thanh lịch”: không có alert nào được gửi. Không có alert nghĩa là không có incident. Không có incident nghĩa là uptime hoàn hảo, theo số liệu đo được. Báo cáo hàng tháng chưa bao giờ trông tốt hơn.

Để đầy đủ, email alert được chuyển tiếp qua một mail server cũng chạy trên Odin. Vì vậy, pipeline alerting hoàn toàn tự khép kín, giống như một con rắn tự ăn đuôi mình và nhờ đó luôn no.

Phần khó chịu

Đây là phần tôi đã trì hoãn. Không có nội dung nào ở đây là hư cấu. Tôi đã thấy tất cả những trường hợp này trong môi trường production: server được xem là không thể thay thế, RAID 0 có backup trên cùng một volume, firewall bị tắt “tạm thời”, cluster Kubernetes chỉ phục vụ một trang, và monitor tự giám sát chính nó. Một số trường hợp xảy ra trong năm nay. Một hoặc hai trường hợp do chính tôi dựng lên khi mới vào nghề.

Hiệu quả thực tế thường rất nhàm chán. Vì vậy, nó thua trong tranh luận trước mắt nhưng lại chứng minh giá trị trong cả một thập kỷ: PUE mà bạn không bao giờ phải nghĩ đến vì đã có người khác thiết kế. Máy được chọn kích thước theo workload thay vì theo hình ảnh chủ quan của người sở hữu. Xác định blast radius trước khi sự cố xảy ra. Backup được kiểm thử bằng cách khôi phục theo lịch, có lời nhắc trên calendar và không cần ai phải làm anh hùng. Redundancy cũng nên nhàm chán: hai thiết bị giá rẻ luôn tốt hơn một thiết bị tuyệt vời trong mọi loại lỗi mà tôi từng được gọi xử lý.

Và datacenter hiệu quả nhất là datacenter bạn không phải tự vận hành. VPS giao việc cung cấp điện, làm mát, redundancy và xử lý hardware failure lúc 3 a.m. cho những người thực hiện chúng ở quy mô lớn, đều đặn và nhàm chán. Đó là lời khen cao nhất mà infrastructure có thể nhận. Bạn chỉ cần làm phần thực sự thú vị là chạy các service của riêng bạn trên đó, trên một machine mà bạn có thể chấp nhận bị mất. Đó là loại machine duy nhất bạn nên dùng để thử nghiệm.

FAQ

Tôi có thực sự nên làm những việc 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 nhận, với cái giá là nhiều cuối tuần bị lãng phí. Nếu thiết lập hiện tại của bạn giống hơn 2 phần, hãy chuyển thẳng đến câu hỏi cuối cùng trong FAQ theo đúng thứ tự, vì thứ tự đó là quy trình phân loại sự cố.

PUE thực sự bao nhiêu là tốt?

Datacenter hyperscale thường đạt khoảng 1.1, một phòng máy doanh nghiệp được vận hành tốt đạt 1.4 đến 1.6, còn một phòng nhỏ không có hệ thống làm mát nhưng có tranh chấp với 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à. Đây là lý do kinh tế rõ ràng để thuê compute từ đơn vị có khả năng vận hành hiệu quả.

Dùng server để sưởi một tòa nhà có phải là chuyện có thật không?

Có, nếu được thực hiện đúng cách. Các dự án sưởi ấm khu vực ở một số quốc gia thu hồi nhiệt thải từ datacenter qua heat exchanger rồi dẫn vào nhà dân bằng đường ống, theo thiết kế, với kỹ thuật và hợp đồng đầy đủ. Ý châm biếm ở trên không phải là nhiệt từ server không thể sưởi ấm một căn phòng. Vấn đề là bạn thực hiện việc đó một cách tình cờ rồi gọi sự cố đó là chiến lược.

Server của tôi đã trông như thế này. Tôi nên làm gì trước?

Tối nay, hãy tạo backup đến một nơi không phải server, sau đó kiểm tra restore. Một backup chưa được kiểm thử chỉ là lời đồn. Thứ hai, cài patch và reboot trong một maintenance window đã lên kế hoạch, thay vì tiếp tục né tránh reboot, để bạn biết thứ gì hỏng khi đang theo dõi. Thứ ba, loại bỏ single point of failure: chuyển DNS và monitoring ra khỏi máy đó. Những việc khác có thể chờ đến một tuần bình tĩnh hơn; 3 việc này thì không.