VPS managed hay không managed: nên chọn loại nào?

VPS managed và không managed: câu trả lời ngắn gọn

Chọn VPS managed hay không managed là vấn đề về khối lượng công việc, không phải vấn đề về sản phẩm. Không managed nghĩa là bạn tự chịu trách nhiệm cập nhật bản vá, cấu hình firewall, sao lưu, monitoring và reboot lúc 2 giờ sáng. Managed nghĩa là nhà cung cấp thực hiện một phần các việc đó thay bạn. Phạm vi hỗ trợ thay đổi rất nhiều giữa các nhà cung cấp. Cách so sánh hữu ích duy nhất là liệt kê những việc mỗi gói loại bỏ khỏi phần việc của bạn, rồi đối chiếu chi phí với số giờ bạn phải tự bỏ ra.

Không có định nghĩa tiêu chuẩn cho từ managed. Với một nhà cung cấp, điều đó có nghĩa là hệ điều hành được cập nhật bản vá và có nhân viên trả lời ticket. Với nhà cung cấp khác, điều đó chỉ có nghĩa là họ đã cài control panel, còn mọi việc phía trên control panel vẫn do bạn phụ trách. Với nhà cung cấp thứ ba, đó là một hợp đồng dịch vụ bằng văn bản kèm thời gian phản hồi. Hai gói cùng dùng từ này có thể khác nhau hoàn toàn ở mọi điểm quan trọng. Vì vậy, hãy đọc tài liệu nêu rõ phạm vi dịch vụ trước khi xem giá. Nếu bạn vẫn chưa xác định máy chủ dùng để làm gì, bạn thực sự có thể làm gì với VPS là câu hỏi nên giải quyết trước.

Các tác vụ phải có người phụ trách

Mỗi server đang chạy đều có cùng một danh sách công việc. Với gói không được quản trị, bạn chịu trách nhiệm cho danh sách đó. Với gói được quản trị, bạn trả phí để nhà cung cấp thực hiện các mục trong danh sách. Hãy đi qua từng mục và ghi tên người phụ trách bên cạnh.

• Cập nhật bản vá cho hệ điều hành và reboot mà các bản cập nhật kernel yêu cầu.
• Duy trì đúng các rule của firewall khi bạn thêm và xóa service. Kiến thức cơ bản về firewall ufw cho VPS trình bày ruleset ban đầu.
• Quyền truy cập SSH: quản lý key, vô hiệu hóa đăng nhập bằng mật khẩu, thu hồi key khi có người rời đi và chuẩn bị cách truy cập lại khi bạn tự khóa quyền truy cập.
• Backup, một bản sao lưu offsite và một lần restore mà bạn đã thực hiện thật sự.
• Monitoring, bao gồm việc biết server còn truy cập được, disk còn đủ dung lượng, service vẫn đang chạy và certificate chưa hết hạn.
• Kiểm tra log và xử lý khi phát hiện điều bất thường trong log.
• Cấu hình service cho web server, database, reverse proxy và queue nếu bạn sử dụng queue.
• Gia hạn certificate và sửa lỗi khi cơ chế gia hạn tự động ngừng hoạt động.
• Capacity, bao gồm việc nhận biết memory sắp cạn trước khi out of memory (OOM) killer phải xử lý thay bạn.
• Ứng phó sự cố, bao gồm việc luôn tỉnh táo và có thể liên lạc vào thời điểm bạn không thể tự chọn.

Phần lớn các công việc này là tác vụ định kỳ và có thể giao cho một script. Ứng phó sự cố là việc không thể giao hoàn toàn cho script, vì cần một người có khả năng đưa ra quyết định. Đó mới là giá trị thực sự mà một gói được quản trị cung cấp. Vì vậy, checklist ở phần dưới tập trung phần lớn câu hỏi vào phạm vi hỗ trợ thay vì việc cập nhật bản vá.

Những việc dịch vụ quản trị thường không bao gồm

Đây là điểm người mua dễ bị thiệt, nên cần xác định rõ. Hợp đồng quản trị thường bao gồm hệ điều hành và phần mềm do nhà cung cấp cài đặt. Phạm vi hỗ trợ dừng ở ranh giới của ứng dụng của bạn.

Code của bạn là trách nhiệm của bạn. Lỗi 500 do ứng dụng của bạn không phải lỗi máy chủ. Nhà cung cấp sẽ xác nhận tiến trình web server đang chạy rồi chuyển ticket lại cho bạn. Đây là ranh giới hợp lý. Đồng thời, đây cũng là khoảng cách lớn nhất giữa kỳ vọng của người mua và phạm vi họ thực sự đã mua.

Các vấn đề ở cấp ứng dụng thường nằm ngoài phạm vi hỗ trợ. Một truy vấn cơ sở dữ liệu chậm, một plugin bị lỗi sau khi update, một cache cấu hình sai hoặc một mail queue không còn xử lý hết: các vấn đề này nằm trên ranh giới hỗ trợ, ngay cả khi nhà cung cấp đã cài phần mềm bên dưới.

Hầu hết việc khôi phục dữ liệu đều nằm ngoài phạm vi hỗ trợ. Backup của nhà cung cấp bảo vệ image của toàn bộ server do nhà cung cấp quản lý và phục vụ trường hợp phần cứng của host bị lỗi. Backup hiếm khi được thiết kế cho trường hợp bạn đã xóa một row, chạy migration lỗi hoặc làm hỏng một file từ sáu tuần trước nhưng hôm nay mới phát hiện. Hãy hỏi thời gian lưu giữ là bao lâu, có thể lấy riêng một file hay không và ai thực hiện việc restore.

Phần mềm do bạn cài đặt là trách nhiệm của bạn. Khi bạn cài Docker, nhà cung cấp thường chịu trách nhiệm cho host, còn bạn chịu trách nhiệm cho mọi thứ bên trong các container.

Tự chỉnh sửa có thể làm mất quyền hỗ trợ. Một số hợp đồng loại một component khỏi phạm vi hỗ trợ sau khi khách hàng trực tiếp chỉnh sửa cấu hình của component đó. Hãy hỏi về điều này nếu bạn dự định tinh chỉnh bất kỳ thành phần nào.

Định giá thời gian của bạn theo phần chênh lệch hằng tháng

Lấy hai báo giá trước mặt bạn và ghi lại phần chênh lệch hằng tháng. Đây là khoản nhà cung cấp tính để loại bỏ các mục trong danh sách trên. Bây giờ, hãy định giá phần đóng góp của bạn trong giao dịch này.

• Một giờ làm việc của bạn có giá trị bao nhiêu, và danh sách đó mất bao nhiêu giờ mỗi tháng sau khi được tự động hóa?
• Mỗi giờ downtime của dịch vụ chạy trên server này tốn bao nhiêu?

Một máy Ubuntu vận hành ổn định, có automatic updates và external monitoring, cần rất ít công việc định kỳ. Phần lớn các tháng không cần xử lý gì. Khi một script đảm nhiệm công việc định kỳ, chi phí thực hiện rất thấp. Các lần gián đoạn mới tốn kém, và managed plan là dịch vụ bán khả năng xử lý những lần gián đoạn đó. Nếu server chạy một dự án cá nhân, outage không gây thiệt hại gì và unmanaged là lựa chọn rõ ràng. Nếu server tiếp nhận đơn hàng, hãy xem xét kỹ liệu support contract có thực sự rút ngắn outage hay không, vì managed provider vẫn phải đọc ticket, tái hiện lỗi và xử lý.

Phần chênh lệch cũng tăng theo số lượng server. Managed fee thường được tính theo từng server, còn automation chỉ cần viết một lần rồi sao chép. Server thứ hai làm giảm một nửa chi phí thực tế của script bạn đã viết cho server đầu tiên, vì vậy hãy đọc cách quản lý nhiều Linux server trước khi cam kết trả phí theo từng server. Để xem các con số cơ sở ở hai phía của phép so sánh, VPS thực sự tốn bao nhiêu mỗi tháng xác định mức sàn, còn đánh đổi giữa VPS và dedicated server trở nên quan trọng khi workload đủ lớn để managed premium chỉ còn là sai số làm tròn.

Câu hỏi cần hỏi nhà cung cấp trước khi trả phí dịch vụ quản trị cao cấp

Hãy hỏi trước khi thanh toán và yêu cầu câu trả lời bằng văn bản. Trang bán hàng không phải là tài liệu xác định phạm vi công việc.

1. Phạm vi công việc bao gồm những gì, theo từng nhiệm vụ? Hãy yêu cầu danh sách cụ thể, không chỉ tài liệu giới thiệu.
2. Dịch vụ hỗ trợ có bao gồm phần mềm tôi tự cài đặt không, hay chỉ bao gồm phần mềm do các bạn cài đặt?
3. Các bạn có tự động cài bản vá không? Các bạn có tự khởi động lại máy cho các bản cập nhật kernel mà không hỏi tôi trước không?
4. Ai chịu trách nhiệm nếu bản vá do các bạn cài làm hỏng ứng dụng của tôi?
5. Các bạn có thực hiện backup không? Backup được lưu ở đâu, giữ trong bao lâu và ai thực hiện việc restore?
6. Gần đây các bạn đã restore server của khách hàng chưa? Quá trình đó mất bao lâu?
7. Thời gian phản hồi ticket là bao lâu? Thời gian này có khác vào lúc 03:00 ngày Chủ nhật không?
8. Tôi có tiếp tục giữ quyền truy cập root không? Việc tôi sử dụng quyền này có làm giảm phạm vi hỗ trợ của các bạn không?
9. Phí được tính theo từng server hay từng account?
10. Nếu tôi rời đi, tôi được mang theo những gì? Một hệ thống nằm bên trong control panel độc quyền có thể khó export.

Câu hỏi 5 quyết định phần lớn các câu hỏi còn lại. Nhà cung cấp trả lời chính xác câu hỏi này cho thấy họ đã từng thực hiện việc đó. Câu trả lời mơ hồ có nghĩa là quy trình restore chưa bao giờ được kiểm thử, và một backup chưa được kiểm thử chỉ là một bản sao. Câu hỏi 5 cũng liên quan đến vị trí lưu trữ: các bản sao thực sự nằm ở đâu là vấn đề pháp lý cũng như vấn đề kỹ thuật, và những điều thực sự quan trọng khi chọn quốc gia đặt hosting sẽ trình bày vấn đề đó.

Con số trung gian: không quản lý cộng với tự động hóa

Hầu hết người đọc kỹ thuật không muốn chọn một trong hai thái cực. Họ muốn một gói không quản lý, trong đó các công việc định kỳ được giao cho máy, còn họ tập trung vào những việc máy không thể đánh giá. Hãy thiết lập ngay trong ngày đầu tiên. Mười phút đầu tiên trên VPS mới là điểm bắt đầu thực tế cho bất kỳ ai chọn gói không quản lý, và tăng cường bảo mật truy cập SSH cũng nên được thực hiện trong cùng phiên đầu tiên.

Cập nhật bảo mật tự động

sudo apt update && sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades

Bây giờ file đó phải chứa APT::Periodic::Update-Package-Lists "1"; và APT::Periodic::Unattended-Upgrade "1";. Nếu thiếu file hoặc có 0 trên một trong hai dòng, thì không có gì chạy và bạn sẽ không nhận được thông báo.

Kiểm tra mà không thay đổi system. Lưu ý package ở dạng unattended-upgrades, còn command ở dạng số ít:

sudo unattended-upgrade --dry-run --debug

Output liệt kê mọi package đã được kiểm tra và kết thúc bằng một dòng như No packages found that can be upgraded unattended khi không có package nào đang chờ cập nhật. Các lần chạy thật được ghi vào /var/log/unattended-upgrades/unattended-upgrades.log, vì vậy hãy kiểm tra ở đó thay vì phỏng đoán.

Kernel update không có tác dụng cho đến khi máy reboot, vì kernel đang chạy là kernel được load lúc boot. File /var/run/reboot-required xuất hiện khi đang chờ reboot. Bạn có thể theo dõi file đó hoặc để máy tự xử lý trong /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Automatic-Reboot-WithUsers "false" trì hoãn reboot khi có người đang đăng nhập. Cách này an toàn hơn trên máy bạn sử dụng tương tác, nhưng vô ích trên máy không có ai đăng nhập. Thiết lập unattended upgrades đầy đủ trên Ubuntu trình bày cú pháp blocklist và các tùy chọn email.

Monitoring chạy ở nơi khác

Một monitor chạy trên server không thể báo cho bạn biết server đang down, vì chính nó cũng down. Hãy đặt check trên host thứ hai hoặc dùng external service. Uptime Kuma để monitoring trạng thái là lựa chọn self-hosted phổ biến, và nó phải nằm trên máy khác với máy được theo dõi.

Tối thiểu hãy theo dõi 4 thứ: khả năng truy cập, mức sử dụng disk, application có trả lời trên port thực tế hay không, và thời hạn certificate. Disk là nguyên nhân thường khiến mọi người gặp sự cố. Một log file hoặc database tăng thêm một ít mỗi ngày có thể làm máy ngừng hoạt động vào thời điểm không có dấu hiệu nào khác dự báo được. Triệu chứng đầu tiên thường là service không thể ghi dữ liệu rồi thoát.

df -h
sudo du -xh --max-depth=1 /var | sort -h
journalctl --disk-usage

Cũng hãy thêm heartbeat. Sau mỗi lần backup hoặc health check thành công, một timer trên server sẽ gọi URL. Monitor sẽ cảnh báo khi cuộc gọi đó không còn đến nữa. Khi đó, một server im lặng vẫn tự tạo ra cảnh báo, điều mà check chỉ theo kiểu pull không thể làm được nếu network path là phần bị hỏng.

Backup đã được restore ít nhất một lần

sudo apt install -y restic
sudo sh -c 'umask 077; printf %s "a-long-random-passphrase" > /root/.restic-pass'
export RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
export RESTIC_PASSWORD_FILE=/root/.restic-pass
sudo -E restic init

restic init chỉ in created restic repository <id> at sftp:... một lần. Chạy command này trên repository đã tồn tại sẽ báo lỗi thay vì ghi đè, đúng với hành vi bạn cần. Hãy giữ một bản sao passphrase ở nơi khác ngoài server. Repository không thể đọc được nếu thiếu passphrase này và không có cách khôi phục.

sudo -E restic backup /etc /home /srv
sudo -E restic snapshots
sudo -E restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
sudo -E restic check

restic snapshots phải liệt kê lần chạy bạn vừa thực hiện với ngày hiện tại. restic check kiểm tra cấu trúc repository và in no errors were found. Bây giờ hãy thực hiện phần mà hầu hết mọi người bỏ qua:

sudo -E restic restore latest --target /tmp/restore-check
ls /tmp/restore-check/etc

File bạn mong đợi hoặc có tồn tại hoặc không, và phát hiện việc đó ngay bây giờ chỉ mất 10 phút. Sau đó, hãy đặt lịch chạy để backup không phụ thuộc vào bạn. Ghi /etc/systemd/system/restic-backup.service:

[Unit]
Description=restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
Environment=RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
Environment=RESTIC_PASSWORD_FILE=/root/.restic-pass
ExecStart=/usr/bin/restic backup /etc /home /srv
ExecStart=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Và /etc/systemd/system/restic-backup.timer:

[Unit]
Description=Run restic backup daily

[Timer]
OnCalendar=daily
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
journalctl -u restic-backup.service -n 30 --no-pager
systemctl list-timers restic-backup.timer

list-timers hiển thị lần chạy tiếp theo và thời gian còn lại. Kết quả trống nghĩa là bạn đã enable service thay vì timer. Đây là lỗi phổ biến nhất ở bước này. Persistent=true chạy job bị bỏ lỡ sau lần boot tiếp theo, nên máy đã tắt qua đêm vẫn thực hiện backup. Backup Restic trên VPS trình bày sâu hơn về bố cục repository và chính sách lưu giữ, còn service và timer của systemd giải thích từng dòng trong unit file.

Tự động hóa không thể thay thế điều gì

Tự động hóa không thể thay thế phán đoán của bạn. Reboot tự động lúc 02:00 vẫn diễn ra dù application có khởi động lại ổn định hay không. Vì vậy, hãy xác nhận mọi service đều tự khởi động được, sau đó chủ động reboot khi bạn vẫn đang thức:

systemctl is-enabled nginx docker
sudo reboot

Unattended upgrade cũng có thể cài một package làm application bị lỗi, và không thành phần nào trong pipeline biết điều đó đã xảy ra. Monitor của bạn sẽ phát hiện sự cố, vì vậy monitor không phải là tùy chọn khi updates đã được tự động hóa. Máy xử lý các công việc định kỳ. Sự cố vẫn do bạn xử lý.

Khi managed đáng với chi phí

Hãy đánh giá công bằng lựa chọn managed. Có 4 tình huống khiến đây là lựa chọn phù hợp.

• Không ai trong nhóm quản trị Linux, và bạn không có kế hoạch thuê người làm việc đó.
• Yêu cầu compliance quy định rõ một bên chịu trách nhiệm patch, và bên đó không thể là bạn.
• Stack thuộc loại mà nhà cung cấp chuyên hỗ trợ, nên đội ngũ của họ đã từng xử lý lỗi giống lỗi của bạn.
• Người lẽ ra phải làm việc này là nhân sự tốn kém nhất của bạn, và 1 giờ làm việc của họ có chi phí cao hơn 1 tháng dùng gói premium.

Managed không tự động an toàn hơn. Các gói managed thường patch nhanh hơn so với một chủ hệ thống thiếu chú ý, và đó là một lợi ích thực tế. Các gói này cũng thường cài control panel, vốn là một ứng dụng lớn hướng ra network, có trang đăng nhập và lịch sử lỗ hổng riêng. Đây có thể là một đánh đổi hợp lý, nhưng vẫn là một đánh đổi.

Quyết định cuối cùng luôn dựa trên cùng một danh sách. Hãy ghi lại 10 tác vụ, đánh dấu bên chịu trách nhiệm cho từng tác vụ trong mỗi báo giá, rồi so sánh phần chênh lệch với giá trị 1 giờ bạn dành để xử lý việc đó. Phần lớn độc giả kỹ thuật làm như vậy sẽ chọn unmanaged và giao các tác vụ định kỳ cho timer. Đây là một lựa chọn có cơ sở, không chỉ là lựa chọn rẻ.

FAQ

VPS managed và VPS unmanaged khác nhau như thế nào?

VPS unmanaged chỉ cung cấp máy chủ và không cung cấp thêm gì, vì vậy bạn tự chịu trách nhiệm cập nhật bản vá, cấu hình firewall, sao lưu, monitoring và reboot sau khi cập nhật kernel. VPS managed chuyển một phần công việc đó cho nhà cung cấp, thường là lớp hệ điều hành và phần mềm họ đã cài cho bạn. Ranh giới chính xác do từng nhà cung cấp quy định, không được xác định chỉ bởi tên gọi. Vì vậy, hãy yêu cầu họ nêu rõ phạm vi theo từng tác vụ bằng văn bản trước khi so sánh hai mức giá.

VPS managed có nghĩa là tôi không cần tự sao lưu không?

Không. Backup của nhà cung cấp thường bảo vệ image của toàn bộ server do nhà cung cấp lưu trữ và dùng trong trường hợp host gặp sự cố. Backup đó hiếm khi giúp được khi bạn đã xóa một file, chạy migration lỗi hoặc làm hỏng dữ liệu từ vài tuần trước nhưng đến hôm nay mới phát hiện. Hãy hỏi snapshot được giữ trong bao lâu, có thể restore một file riêng lẻ hay không và ai thực hiện việc restore. Sau đó, hãy giữ bản sao offsite của riêng bạn bằng một tool như restic và test bản sao đó bằng restic restore latest --target /tmp/restore-check để chắc chắn nó hoạt động.

VPS managed có an toàn hơn VPS unmanaged không?

Không phải mặc nhiên. Managed plan cập nhật bản vá nhanh hơn một người quản trị không bao giờ đăng nhập, nên thực sự giúp giảm rủi ro. Nhiều managed plan cũng cài control panel. Panel là một application lớn hướng ra network, có login page riêng và lịch sử vulnerability riêng. Một máy unmanaged có automatic security updates, firewall đóng các kết nối không cần thiết, SSH chỉ dùng key và không có dịch vụ thừa nào listening sẽ là mục tiêu nhỏ hơn một máy managed đang chạy panel.

Tôi có thể bắt đầu với unmanaged rồi chuyển sang managed sau không?

Thông thường là có, nhưng hiếm khi chỉ cần bật một checkbox. Nhà cung cấp thường audit hoặc rebuild server trước khi nhận trách nhiệm quản lý, vì họ sẽ không support một configuration mà họ không thể kiểm tra. Hãy hỏi quy trình onboarding gồm những gì, có cần reinstall hay không và những gì bạn tự cấu hình có tiếp tục nằm ngoài scope sau đó hay không.

Tôi có tiếp tục giữ quyền root trên VPS managed không?

Với hầu hết managed VPS plan, bạn vẫn giữ quyền root, nhưng quyền root có liên quan trực tiếp đến scope hỗ trợ. Một số nhà cung cấp sẽ giảm hoặc hủy hỗ trợ cho component mà bạn tự sửa, còn một số khác sẽ rebuild theo template của họ nếu ticket cần xử lý sâu. Hãy yêu cầu quy định này bằng văn bản trước khi bạn tinh chỉnh bất kỳ thứ gì. Đồng thời, hãy lưu các file configuration trong version control để một lần rebuild chỉ mất một giờ thay vì cả cuối tuần.