Quản lý nhiều server Linux: chọn tool theo quy mô

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

Không phải một tool duy nhất, mà là một stack gọn được chọn theo số lượng server bạn thực sự có. Đây là input duy nhất quan trọng, nhưng mọi bài tổng hợp về "Linux server management tools" đều bỏ qua. Sai lầm kinh điển là dùng giải pháp dành cho 200 server cho 4 VPS, rồi mất cả tháng nuôi tool thay vì quản lý server. Sai lầm kinh điển thứ hai là người có 18 server vẫn SSH thủ công vào từng máy, áp dụng cùng một thay đổi theo 18 cách hơi khác nhau.

Vì vậy, guide này được tổ chức theo quy mô fleet: 2 đến 5 server, 5 đến 20 server và trên 20 server, cùng một lớp dùng chung cho mọi quy mô mà gần như không ai ghi lại: inventory, key hygiene, một phương thức truy cập duy nhất và các bản backup mà bạn đã thực sự restore thành công. Với mỗi tool, bạn sẽ biết 3 điều: nó thay thế gì, setup mất bao nhiêu phút và gotcha nào thực sự dễ gây sự cố. Tôi đã vận hành một VPS host trong 15 năm; danh sách dưới đây là những gì vẫn hoạt động khi gặp outage lúc 2 giờ sáng, không phải những gì trông tốt trong demo.

Điều kiện cần và những điểm cần lưu ý

Bạn cần SSH bằng key đã hoạt động đến mọi server. Nếu bạn vẫn phải nhập password, hãy xử lý việc đó trước. Việc này mất khoảng mười phút và mọi phần bên dưới đều giả định bạn dùng key. Bạn cũng cần một user có quyền sudo nhưng không phải root, cùng các server đang chạy phiên bản hiện tại. Các command ở đây giả định Ubuntu 24.04, nhưng ngoài apt ra thì không có gì phụ thuộc riêng vào Ubuntu.

Trước khi bắt đầu với các tool, có hai cảnh báo cần nói rõ. Thứ nhất, cài quá nhiều tool cũng trở thành một vấn đề quản trị. Mỗi agent bạn cài là một daemon khác cần patch trên mọi máy. Vì vậy, chỉ nên thêm một tool khi nó thay thế được công việc thủ công bạn đã làm trong tuần này, không phải chỉ vì nó trông có vẻ hữu ích. Thứ hai, mọi thứ ở đây đều là free software, còn chi phí thực tế là thời gian thiết lập. Vì vậy mỗi tool đều có ước tính theo phút. Nếu ước tính ghi là một buổi chiều, hãy tin con số đó.

2 đến 5 server: ~/.ssh/config là công cụ bị đánh giá thấp nhất mà bạn đã có

Nó thay thế: file văn bản chứa các địa chỉ IP, việc đào lại shell history (ssh 203.0 rồi nhấn Ctrl-R và cầu may), cùng việc gõ -p 2222 -i ~/.ssh/other_key mãi mãi. Chi phí thiết lập: 15 phút, chỉ một lần. Điểm cần lưu ý: socket multiplexing cũ, được trình bày bên dưới.

Ở quy mô này, bạn không cần phần mềm; bạn chỉ cần cấu hình client sẵn có đúng cách. ~/.ssh/config biến mỗi server thành một tên gồm một từ và mã hóa tuyến kết nối để bạn không phải nghĩ về việc này nữa:

Host *
    ServerAliveInterval 30
    ControlMaster auto
    ControlPath ~/.ssh/cm-%r@%h-%p
    ControlPersist 10m

Host bastion
    HostName 10.0.0.10
    User matt

Host web1
    HostName 10.8.0.11
    User matt
    ProxyJump bastion

Host db1
    HostName 10.8.0.12
    User matt
    Port 2222
    ProxyJump bastion

Ba thiết lập đảm nhiệm phần việc chính. ProxyJump định tuyến kết nối qua bastion trong một bước, nên ssh db1 từ quán cà phê sẽ tự động tạo tunnel qua bastion, không cần agent forwarding, không cần các câu lệnh ProxyCommand phức tạp, và các server private hoàn toàn không cần public SSH port (xem thêm trong phần nội dung dùng chung). ControlMaster auto cùng với ControlPersist multiplex các kết nối trên một TCP session, nên ssh, scp hoặc rsync thứ hai và các lần sau đến cùng một host sẽ kết nối ngay thay vì đàm phán lại. Sự khác biệt này rất rõ khi dùng Ansible. Ngoài ra, vì scp, rsync và Ansible đều đọc cùng file này, mọi tên bạn định nghĩa ở đây đều hoạt động ở mọi nơi.

Điểm cần lưu ý là master connection có thể tiếp tục tồn tại sau khi không còn hữu ích, và hai chế độ lỗi này có biểu hiện khác nhau. Khi server reboot hoặc Wi-Fi bị ngắt, master process vẫn giữ một TCP session đã chết mà chưa phát hiện ra. Khi đó, ssh web1 tiếp theo sẽ âm thầm treo trên một socket không dẫn đến đâu. Riêng sshd giới hạn số session trên mỗi connection ở mức 10 (MaxSessions trong sshd_config), nên session multiplex thứ 11 đến một host sẽ in ra:

mux_client_request_session: session request failed: Session open refused by peer

Cả hai lỗi đều có cùng cách xử lý: ssh -O exit web1 sẽ dừng master, sau đó connection tiếp theo sẽ tạo một master mới. Đôi khi bạn cũng có thể thấy ControlSocket /home/matt/.ssh/cm-matt@10.8.0.11-22 already exists, disabling multiplexing. Lỗi này không nghiêm trọng: hai session đã chạy đua với nhau, và connection vẫn hoạt động, chỉ là không được multiplex.

Ở quy mô này còn có hai công cụ hỗ trợ. tmux trên mỗi server thay thế nohup, tránh mất công việc khi Wi-Fi bị ngắt và tránh tình huống “tôi không thể đóng laptop vì migration đang chạy”. Chi phí thiết lập: sudo apt install -y tmux, mất 2 phút, cộng thêm việc ghi nhớ tmux new -s work và tmux attach -t work. Điểm cần lưu ý là việc lồng tmux: tmux bên trong tmux sẽ nuốt phím prefix, nên hãy chạy nó trên server hoặc laptop, không chạy trên cả hai. Nếu bạn chạy các agent session dài hạn, điều này càng quan trọng. Đây cũng là mô hình giống như chạy Claude Code trong tmux trên VPS, trong đó session phải tồn tại lâu hơn SSH connection.

File alias dùng chung thay thế việc nhập lại 12 one-liner yêu thích trên từng máy. Lưu một .bash_aliases trong git repo rồi pull nó về từng server. Điểm cần lưu ý là file sẽ lệch ngay khi bạn chỉnh trực tiếp trên một server thay vì chỉnh trong repo. Đây cũng là lần đầu bạn thấy rõ lý do tier tiếp theo tồn tại.

5 đến 20 server: cấu hình dưới dạng code, nếu không thì drift sẽ thắng

Sau khoảng 5 server, cách “tôi cứ làm thủ công trên từng máy” không còn là phương pháp mà trở thành lời tự tự trấn an. Các tool ở cấp độ này đều xử lý cùng một vấn đề: drift.

Ansible thay thế vòng lặp shell qua danh sách hostname, trang wiki có tiêu đề “cấu hình server mới” nhưng đã lỗi thời 3 bước, và sự lo lắng vì không biết web3 đã nhận bản sửa hay chưa. Chi phí thiết lập: 30 phút để có playbook đầu tiên chạy được, sudo apt install -y ansible trên laptop hoặc management box của bạn (apt cung cấp bản Ansible cũ hơn, nhưng đủ cho mọi nội dung ở đây; cách cài qua pipx trong tutorial sẽ cài các phiên bản hiện tại), không cần agent trên server, mọi thứ chạy qua SSH config bạn đã tạo. Đây là nâng cấp đơn lẻ lớn nhất trên trang này. Toàn bộ quy trình có trong tutorial tạo playbook đầu tiên với Ansible; dưới đây là cấu trúc inventory cần dùng:

[web]
web1 ansible_host=10.8.0.11
web2 ansible_host=10.8.0.12

[db]
db1 ansible_host=10.8.0.21 ansible_port=2222

[all:vars]
ansible_user=matt
ansible_ssh_common_args='-o ProxyJump=bastion'

Vì Ansible gọi binary OpenSSH, ~/.ssh/config bạn đã viết ở phần trước sẽ được áp dụng luôn. Inventory chỉ gồm các tên như web1 cũng sẽ hoạt động mà không cần vars. Các vars ở trên giúp inventory tự chứa đủ cấu hình. Điều này hữu ích khi bạn chạy nó từ một máy không phải laptop của mình.

Kiểm tra bằng ansible all -i inventory.ini -m ping; kết quả đúng sẽ in "ping": "pong" cho từng host, bằng màu xanh lá. Lỗi đầu tiên bạn thường gặp sẽ trông như sau:

web1 | UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: matt@10.8.0.11: Permission denied (publickey).",
    "unreachable": true
}

Đó không phải lỗi của Ansible. ssh matt@10.8.0.11 thuần cũng thất bại theo cùng cách. Luôn sửa SSH trước; Ansible chỉ hoạt động tốt khi lớp bên dưới nó hoạt động tốt. Một điểm cần lưu ý khác: Ansible cần Python trên máy của bạn và, với gần như mọi module bao gồm ping, cả trên server. Vì vậy, một image tối giản thực sự có thể trả về /usr/bin/python3: not found. Chạy một apt install python3 là đủ và lỗi này sẽ không xuất hiện nữa. Với cả fleet gồm các image trống, module raw, một trong số ít module không cần Python trên remote, có thể tự cài Python cho bạn.

unattended-upgrades thay bạn áp dụng security patch cho N server. Ubuntu Server 24.04 mặc định đã cài sẵn và thường đã bật để nhận security update, nên việc cần làm ở đây là xác minh, không phải cài đặt:

cat /etc/apt/apt.conf.d/20auto-upgrades

Cả hai dòng phải kết thúc bằng "1". Một số image tối giản và cloud image tắt tính năng này. sudo dpkg-reconfigure -plow unattended-upgrades sẽ ghi lại file đó nếu image của bạn đang tắt. Chi phí thiết lập: 2 phút để kiểm tra trên mỗi server, hoặc 1 Ansible task cho tất cả server. Điểm cần lưu ý: mặc định tool này không bao giờ reboot server, nên security update cho kernel sẽ ở trạng thái áp dụng dở cho đến khi bạn reboot. Hướng dẫn riêng về unattended-upgrades trình bày cách bật reboot tự động, chọn nội dung được patch và đọc log của tool.

Monitoring tập trung thay thế việc biết sự cố từ khách hàng, vốn là hệ thống monitoring đắt giá nhất từng được tạo ra. Có 2 tool, mỗi tool phù hợp với một câu hỏi: Uptime Kuma trả lời “dịch vụ có đang hoạt động không?” bằng các check HTTP, TCP và ping, gửi alert đến bất kỳ nơi nào, đồng thời chỉ mất 10 phút để chạy bằng Docker; Zabbix trả lời “dịch vụ có sắp ngừng hoạt động không?” bằng xu hướng disk, memory và CPU qua agent trên từng host, nhưng thực tế cần cả một buổi chiều để thiết lập. Bắt đầu với Kuma. Thêm Zabbix khi tình trạng “đang hoạt động nhưng đã suy giảm” bắt đầu khiến bạn mất tiền. Điểm cần lưu ý của cả hai là vị trí triển khai. Vấn đề này đủ quan trọng để được đề cập trong phần lỗi thường gặp bên dưới.

Web panel, chỉ dùng khi thật sự cần. Webmin thay thế việc phải nhớ Ubuntu lưu các thiết lập ở đâu. Với team có nhiều mức độ kỹ năng khác nhau hoặc server chỉ được bạn truy cập 2 lần mỗi năm, tool này thực sự hữu ích; thiết lập mất 10 phút. Điểm cần lưu ý là đây là một web application tương đương root, đang listening trên port 10000, và Internet liên tục scan port này. Nếu chạy nó, hãy bind vào localhost hoặc địa chỉ VPN, không bao giờ bind vào 0.0.0.0 trên public interface. Nếu bạn định dùng panel vì SSH có vẻ chậm, hãy đọc lại phần trước; ~/.ssh/config kết hợp với Ansible sẽ nhanh hơn bất kỳ panel nào sau khi được cấu hình.

20+ máy chủ: giới hạn thực tế của hướng dẫn này

Khi quản lý hơn 20 máy chủ, bạn đang vận hành một fleet và toolchain bắt đầu thay đổi: dùng Terraform hoặc OpenTofu để bản thân các máy chủ có thể tái tạo được; dùng cloud-init hoặc golden image để một máy có thể thay thế thay vì phải sửa chữa; dùng cấu hình pull-based hoặc CI pipeline để chạy Ansible, vì push từ laptop không còn mở rộng tốt; và dùng hệ thống quản lý secrets thực tế. Bản thân Ansible không tự gặp vấn đề khi có 20 máy chủ; nhiều đơn vị vẫn chạy Ansible trên hàng trăm node. Tuy nhiên, các quy trình xung quanh Ansible phải được tăng cường, và đó là một chủ đề khác với phạm vi bài viết của trang này. Nếu bạn đang vận hành ở quy mô đó, phần bên dưới vẫn dành cho bạn, vì inventory, key và kỷ luật quản lý quyền truy cập chính là những điều mà các công cụ quản lý fleet giả định bạn đã có.

Lớp quản trị không ai ghi lại

Bốn thực hành này áp dụng cho mọi quy mô hệ thống. Bỏ qua chúng là lý do số lượng server khiến công việc có vẻ nặng nề hơn thực tế.

Tệp inventory, kể cả chỉ là tệp văn bản. Ngay khi có ba server, hãy ghi lại: tên, IP, nhà cung cấp, dịch vụ đang chạy và lý do server đó tồn tại. Một servers.md trong git repo là đủ dùng; Ansible inventory ở trên tốt hơn vì nó là tài liệu có thể thực thi. Nó thay thế cho câu hỏi lúc 2 giờ sáng: “Khoan, 10.0.0.40 là gì vậy?” Chi phí thiết lập: mười phút. Điểm cần lưu ý: cách này chỉ hiệu quả nếu việc tạo server và thêm dòng tương ứng diễn ra cùng lúc, không phải hai việc tách biệt.

Quản lý key đúng cách: rotation ngay, dùng SSH CA khi cần. Liệt kê nơi các key đang được lưu (cat ~/.ssh/*.pub ở phía bạn, ~/.ssh/authorized_keys ở phía mỗi server), xóa key của laptop cũ và đồng nghiệp không còn làm việc, đồng thời rotation mọi key đã đủ cũ đến mức bạn không thể nói rõ chúng từng được lưu hoặc sử dụng ở đâu. SSH certificate authority, dùng certificate được ký với thời hạn ngắn thay cho key tĩnh, là cách làm trưởng thành hơn. Tuy nhiên, lời khuyên thực tế là với dưới mười server, quản lý authorized_keys có kỷ luật qua Ansible đã mang lại 90% lợi ích, với 10% quy trình rườm rà.

Chỉ một đường truy cập, không phải hai mươi. Mỗi cổng SSH public làm tăng attack surface theo số lượng server. Mô hình có thể mở rộng là dùng một bastion host, hoặc tốt hơn là WireGuard VPN trên một VPS do bạn kiểm soát, rồi bind SSH của mọi server còn lại chỉ vào địa chỉ private. Các dòng ProxyJump trong cấu hình ở trên đã giả định mô hình này. Bất kỳ dịch vụ nào bắt buộc phải public đều nên được cấu hình fail2ban ngay. Chi phí thiết lập: một giờ, chỉ một lần. Điểm cần lưu ý: hãy xác nhận phương án dự phòng (console access của nhà cung cấp) hoạt động trước khi đóng cổng 22 trên mọi server, không phải sau đó.

Backup phải được kiểm thử bằng cách restore. Một bản backup chưa được kiểm thử chỉ là một giả định. Dù bạn dùng cơ chế nào — snapshot của nhà cung cấp, restic, rsync sang một máy khác — công cụ thực sự quan trọng là mục lịch nhắc bạn restore một server lên VPS mới và xác nhận server khởi động cũng như phục vụ được. Mọi câu chuyện thảm họa về backup mà tôi từng nghe trong mười lăm năm làm hosting đều có câu: “Chúng tôi có backup.”

Các lỗi thường gặp

Các tình huống lỗi khi vận hành nhiều server không bắt nguồn từ công cụ mà từ thói quen. Gần như mọi vấn đề đều quy về 4 lỗi sau.

Server không đồng nhất. Mỗi máy được cấu hình thủ công, khác nhau ở những chi tiết khó nhận ra, và không ai có thể dựng lại máy đó. Bạn thường chỉ phát hiện ra khi ổ đĩa hỏng. Cách xử lý không cầu kỳ: mọi thay đổi phải đi qua Ansible, hoặc ít nhất phải được ghi thêm vào phần của server đó trong tài liệu inventory. Bất kỳ server nào mà chiều nay bạn không thể dựng lại chỉ từ ghi chú đều là technical debt, với thời hạn xử lý do hoàn cảnh quyết định.

Mở firewall “tạm thời”. Bạn chạy ufw allow 5432 để debug, nhưng 18 tháng sau Postgres vẫn public trên Internet. Kiểm tra bằng sudo ufw status numbered trên từng máy, hoặc kiểm tra một lần bằng ansible all -i inventory.ini -a "ufw status numbered" --become, rồi xóa mọi rule mà bạn không thể nêu lý do hiện tại. Nếu một rule thực sự chỉ tạm thời, hãy nhập lệnh ufw delete tương ứng trong cùng cửa sổ tmux trước khi đóng cửa sổ đó.

Đặt hệ thống monitoring trên chính server được monitor. Nếu Uptime Kuma chạy trên server mà nó theo dõi, cảnh báo “mọi thứ đều down” cũng sẽ down. Khi đó, bạn đã dựng một phiên bản nhỏ hơn và trớ trêu hơn của datacenter kém hiệu quả nhất thế giới. Monitoring phải nằm trong một failure domain khác: VPS giá rẻ của một nhà cung cấp khác là lựa chọn kinh điển. Tối thiểu, hãy dùng một external free-tier check để theo dõi chính hệ thống monitoring.

Dùng root qua SSH ở mọi nơi. Dùng chung một root key cho toàn bộ fleet có nghĩa là chỉ cần một laptop bị lộ là kẻ tấn công có toàn quyền trên mọi máy. Ngoài ra, audit log cũng không cho biết ai đã làm gì. Hãy dùng user riêng cho từng người, sudo và PermitRootLogin no trong /etc/ssh/sshd_config trên mọi host. Một lần nữa, việc này chỉ cần một Ansible task 3 dòng thay vì cả buổi gõ lệnh thủ công.

Khi fleet vượt quá vài máy, playbook Ansible đầu tiên của bạn sẽ tự động hóa các phần lặp lại.

FAQ

Công cụ miễn phí nào tốt nhất để quản lý nhiều máy chủ Linux?

Với 2 đến 5 máy chủ, một ~/.ssh/config được viết tốt kết hợp với tmux hiệu quả hơn bất kỳ công cụ nào bạn có thể cài. Khi có khoảng 5 máy chủ trở lên, Ansible là lựa chọn tiêu chuẩn: không cần agent, miễn phí, chạy qua SSH sẵn có và biến việc thiết lập máy chủ thành các file trong git. Thêm Uptime Kuma để cảnh báo trạng thái up/down; mọi công cụ được nêu trong hướng dẫn này đều là phần mềm miễn phí.

Có thể quản lý nhiều máy chủ Linux mà không dùng Ansible không?

Có. Với dưới khoảng 5 máy chủ, một SSH config tốt, một file alias dùng chung và tính kỷ luật là đủ; nhiều người vẫn quản lý theo cách này trong nhiều năm. Khi vượt quá quy mô đó, giải pháp thay thế Ansible không phải là “không làm gì”, mà là cấu hình bị lệch không được ghi nhận: 18 máy chủ, mỗi máy được cấu hình thủ công hơi khác nhau. Nếu Ansible có vẻ nặng, hãy bắt đầu bằng một playbook chỉ quản lý authorized_keys và unattended-upgrades; riêng việc này đã đủ bù cho thời gian học.

Làm cách nào chạy cùng một lệnh trên nhiều máy chủ Linux cùng lúc?

ansible all -i inventory.ini -a "uptime" là lựa chọn gọn nhất và không cần playbook, chỉ cần file inventory. Với công việc tương tác trên nhiều máy theo từng ô cạnh nhau, tmux có thể phát thao tác bàn phím đến mọi pane bằng setw synchronize-panes on. Tuy nhiên, hãy chỉ xem đây là một cách tiện dụng nhất thời, vì phát lệnh tương tác đến các máy chủ production là cách một lỗi gõ biến thành sự cố với số lần tương ứng.

Có cần control panel như Webmin để quản lý máy chủ Linux không?

Không cần. Những gì control panel làm được thì SSH và Ansible thực hiện nhất quán hơn. Webmin phù hợp khi những người có trình độ khác nhau cùng quản trị một nhóm máy chủ, hoặc khi bạn ít khi truy cập một máy chủ đến mức việc tìm lại các đường dẫn cấu hình thực sự tốn thời gian. Nếu chạy Webmin, hãy xem nó như một web app tương đương root: bind vào localhost hoặc địa chỉ VPN, không bao giờ bind vào public interface.

Một người có thể quản lý thực tế bao nhiêu máy chủ Linux?

Nếu quản trị thủ công, chất lượng thường giảm trước khi đạt 10 máy chủ. Với config as code, tự động patch và monitoring tập trung, một người cẩn thận có thể vận hành 20 đến 50 máy chủ như một công việc bán thời gian; yếu tố giới hạn là tần suất xảy ra lỗi mới lạ, không phải công việc bảo trì thường ngày. Con số quan trọng không phải số máy chủ trên mỗi admin, mà là số snowflake trên mỗi admin: giữ con số này gần 0 thì giới hạn có thể quản lý sẽ rất cao.