Gói hệ thống có thể xoá trên AlmaLinux khi dùng FastPanel

Khi VPS chỉ dùng để làm web server, tốt nhất nên loại bỏ các gói và dịch vụ không cần thiết.

Việc này giúp:

  • Giảm lượng tài nguyên tiêu hao – RAM và CPU được giải phóng
  • Giảm bề mặt tấn công (attack surface) – Ít dịch vụ = Ít lỗ hổng
  • Tăng hiệu suất cho WordPress, PHP-FPM, MariaDB
  • Hệ thống gọn, sạch, dễ quản lý và giám sát hơn

Bài viết này tổng hợp các gói/dịch vụ có thể xoá và giải thích rõ chức năng để bạn tự quyết định có nên giữ hay không.

Nội dung đặc biệt phù hợp cho những ai đang sử dụng và cài đặt trên hệ điều hành AlmaLinux.

Lưu ý quan trọng: Toàn bộ các lệnh và hướng dẫn trong bài viết đều đã được kiểm chứng và chạy ổn định trên AlmaLinux 8. Tuy nhiên, để đảm bảo an toàn tuyệt đối, bạn vẫn nên tạo backup hoặc snapshot VPS trước khi thực hiện, đề phòng cấu hình hệ thống của bạn có sự khác biệt.

1️⃣ Kiểm tra danh sách dịch vụ & gói trước khi xoá

✔️ Dịch vụ đang chạy

systemctl list-units --type=service --state=running

✔️ Tất cả dịch vụ (kể cả không chạy)

systemctl list-unit-files --type=service

✔️ Kiểm tra port mở

ss -tulnp

✔️ Danh sách gói cài trên hệ thống

dnf list installed

2️⃣ Chi tiết các gói & dịch vụ có thể xoá

Dưới đây là danh sách đầy đủ theo đúng thực tế VPS chạy web bằng Nginx + FastPanel.

🔥 1. firewalld — Firewall mặc định trên Almalinux

Chức năng

  • Tường lửa mặc định, quản lý zone, rule
  • Nhưng nhiều admin dùng nftables, CSF, hoặc firewall tùy chỉnh → không cần firewalld

Nên xoá khi

  • FastPanel sử dụng nftables làm backend và iptables làm frontend nên có thể xoá

Lệnh xoá:

systemctl stop firewalld
systemctl disable firewalld
dnf remove -y firewalld

🔥 2. postfix — Mail Server cục bộ (cân nhắc)

Chức năng

  • Gửi mail nội bộ từ hệ thống Linux
  • Nhưng WordPress dùng SMTP plugin, FastPanel có SMTP riêng → postfix không còn cần thiết
  • Trừ khi bạn chạy mail server nếu không thì xoá

Nên xoá khi

  • Website không gửi mail bằng PHP mail()
  • Dùng SMTP như Gmail, SendGrid, Mailgun, Amazon SES
  • FastPanel có chức năng theo tên miền nên cân nhắc

Lệnh xoá:

systemctl stop postfix
systemctl disable postfix
dnf remove -y postfix
dnf remove -y cyrus-sasl-plain cyrus-sasl-md5 cyrus-sasl-sql

🔥 3. chrony — Đồng bộ thời gian (NTP)

Chức năng

  • Giữ đồng hồ hệ thống chính xác với NTP server

Cân nhắc xoá khi

  • Bạn dùng Cloudflare Time, NTP server khác
  • VPS provider tự động đồng bộ thời gian

Lệnh xoá:

systemctl stop chronyd
systemctl disable chronyd
dnf remove -y chrony

🔥 4. cockpit — Web UI quản lý Server

Chức năng

  • Giao diện web quản lý Linux qua port 9090
  • Rất nặng – tiêu tốn nhiều RAM
  • Không cần khi dùng FastPanel

Nên xoá khi

  • Bạn dùng FastPanel làm giao diện chính
  • Chỉ quản lý qua SSH

Lệnh xoá:

systemctl stop cockpit
systemctl disable cockpit
dnf remove -y cockpit*

🔥 5. exim / dovecot — Mail server đầy đủ

Chức năng

  • exim: mail transfer agent (MTA)
  • dovecot: IMAP/POP3 mail server
  • Nếu bạn tạo email theo tên miền trên FastPanel thì nên giữ lại

Không cần khi

  • VPS chỉ chạy web, không host mail
  • Dùng dịch vụ email riêng như Google Workspace, Zoho Mail

Lệnh xoá:

dnf remove -y exim dovecot

🔥 6. bind & bind-utils — DNS Server (Cân nhắc)

Chức năng

  • Chạy DNS server (BIND) trên VPS
  • Nhưng phần lớn domain dùng Cloudflare / DNS nhà cung cấp

Nên xoá khi

  • VPS không chạy DNS authoritative
  • DNS được quản lý ở nơi khác (Cloudflare, Route53…)
  • Cân nhắc nếu set dns trên FastPanel

Lệnh xoá:

dnf remove -y bind bind-utils

🔥 7. vsftpd — FTP Server

Chức năng

  • FTP server cổ điển
  • Nguy hiểm & lạc hậu – truyền dữ liệu không mã hóa
  • FastPanel + SSH đều hỗ trợ SFTP (an toàn hơn)

Lệnh xoá:

dnf remove -y vsftpd

3️⃣ Các dịch vụ hệ thống không cần thiết

❌ NFS – Chia sẻ file mạng

dnf remove -y nfs-utils

❌ rpcbind – Dịch vụ dùng cho NFS

dnf remove -y rpcbind

❌ cups – Dịch vụ in ấn

dnf remove -y cups

❌ openldap / nss-pam-ldap

Hầu hết VPS không cần LDAP authentication.

dnf remove -y openldap nss-pam-ldapd

❌ selinux-policy-devel / setroubleshoot

Khi cài FastPanel bắt buộc tắt SELinux rồi nên xoá cho nhẹ.

dnf remove -y setroubleshoot setroubleshoot-server

❌ bluetooth, modem-manager, wpa_supplicant

VPS không có Bluetooth hay WiFi.

dnf remove -y bluez*
dnf remove -y ModemManager
dnf remove -y wpa_supplicant

❌ polkit / polkit-libs

⚠️ Polkit dùng cho phân quyền GUI / Cockpit / systemd. Nếu bạn không chạy Cockpit, Panel khác, GUI → có thể remove để giảm vector tấn công. (FastPanel không dùng, nhưng vẫn nên cẩn thận)

dnf remove -y polkit polkit-pkla-compat

❌ avahi, avahi-libs

Dịch vụ tự động phát hiện mạng LAN – VPS không dùng.

dnf remove -y avahi avahi-libs

❌ traceroute, tcpdump (cân nhắc)

❗ Không nên xoá nếu bạn còn sử dụng để debug mạng. Nhưng nếu bạn muốn hệ thống cực sạch → có thể gỡ.

dnf remove -y traceroute tcpdump

❌ rsh, rlogin, rcp

Giao thức từ thời “cổ đại” – không nên có mặt trong bất kỳ VPS nào.

dnf remove -y rsh rsh-server

❌ telnet

Giao thức cũ, nguy hiểm – không còn ai dùng trong môi trường production.

dnf remove -y telnet

❌ pcsc-lite / smartcard

pcsc-lite và pcsc-lite-libs là bộ thư viện + daemon để giao tiếp với smart card, thẻ bảo mật, USB token, HSM.

👉 VPS web server (Nginx, MariaDB, FastPanel) hoàn toàn KHÔNG bao giờ dùng smartcard.

Xoá sẽ tiết kiệm RAM và loại bỏ 1 daemon không cần thiết.

dnf remove -y pcsc-lite pcsc-lite-libs

4️⃣ Dọn dẹp hệ thống sau khi loại bỏ gói thừa

Xóa cache DNF

dnf clean all

Xóa dependency không còn dùng

dnf autoremove -y

5️⃣ Kiểm tra lại dịch vụ quan trọng

Sau khi xoá, đảm bảo các dịch vụ quan trọng vẫn hoạt động bình thường:

✅ Nginx

systemctl status nginx

✅ MariaDB

systemctl status mariadb

✅ PHP-FPM

systemctl status fp2-php*-fpm.service

✅ FastPanel

systemctl status fastpanel2

6️⃣ Tổng Kết

✨ Lợi ích khi loại bỏ gói thừa:

  • VPS nhẹ hơn, load thấp – RAM và CPU được giải phóng cho các dịch vụ chính
  • Ít cổng mở, ít dịch vụ nền → bảo mật hơn, giảm bề mặt tấn công
  • Tối ưu tài nguyên cho Nginx, PHP-FPM, MariaDB
  • Hệ thống sạch, dễ giám sát – Dễ phát hiện vấn đề khi có ít dịch vụ chạy
  • Khởi động nhanh hơn – Ít service cần start khi reboot
  • Update nhanh hơn – Ít package cần update

Khuyến nghị:

  • Luôn tạo snapshot/backup trước khi thực hiện
  • Xoá từng gói một và kiểm tra sau mỗi lần xoá
  • Theo dõi log hệ thống trong 24-48h sau khi tối ưu
  • Ghi chép lại các gói đã xoá để tiện tham khảo sau này

Bài viết được viết dựa trên kinh nghiệm thực tế với AlmaLinux 8 + FastPanel.

Khi làm việc với VPS, việc chọn đúng định dạng nén như TAR, ZIP, TAR.GZ (gzip/pigz), TAR.BZ2 (bzip2/pbzip2), TAR.XZ (xz/pxz), 7Z (-mx5/-mx9) hay TAR.ZST (zstd) có thể giúp tăng tốc độ backup, transfer và deployment, đồng thời tiết kiệm đáng kể thời gian và tài nguyên hệ thống.

Bài viết này sẽ so sánh chi tiết các định dạng nén phổ biến với benchmark thực tế trên VPS 6 cores, 12GB RAM.

1. Tổng Quan Các Định Dạng Nén

1.1. ZIP (.zip)

Đặc điểm:

  • Định dạng phổ biến nhất, được hỗ trợ mọi nơi (Windows, Linux, Mac)
  • Nén và giải nén đơn luồng (single-threaded)
  • Tỷ lệ nén trung bình
  • Hỗ trợ mã hóa và password

Khi nào dùng:

  • Cần chia sẻ file với Windows users
  • File cần giải nén trên nhiều hệ điều hành
  • Không cần tỷ lệ nén cao nhất

1.2. TAR (.tar)

Đặc điểm:

  • KHÔNG nén, chỉ đóng gói (archive) nhiều file thành 1 file
  • Rất nhanh (chỉ là copy file)
  • Giữ nguyên permissions và ownership (quan trọng trên Linux)
  • Thường kết hợp với GZIP hoặc BZIP2

Khi nào dùng:

  • Backup hệ thống Linux/Unix
  • Cần giữ nguyên quyền file
  • Kết hợp với compression algorithm khác

1.3. TAR.GZ / TGZ (.tar.gz, .tgz)

Đặc điểm:

  • TAR + GZIP compression
  • Tỷ lệ nén tốt
  • GZIP thông thường là đơn luồng
  • Có thể dùng pigz (parallel gzip) để nén multi-threaded

Khi nào dùng:

  • Backup/transfer file trên Linux
  • Cần tỷ lệ nén tốt và tốc độ nhanh
  • Standard cho source code và packages

1.4. TAR.BZ2 (.tar.bz2, .tbz)

Đặc điểm:

  • TAR + BZIP2 compression
  • Tỷ lệ nén cao hơn GZIP (10-15%)
  • Chậm hơn GZIP đáng kể
  • Có thể dùng pbzip2 (parallel bzip2)

Khi nào dùng:

  • Bandwidth giới hạn, cần file nhỏ nhất
  • Không quan tâm thời gian nén
  • Lưu trữ dài hạn

1.5. TAR.XZ (.tar.xz, .txz)

Đặc điểm:

  • TAR + XZ (LZMA2) compression
  • Tỷ lệ nén cao nhất trong các format phổ biến
  • Rất chậm khi nén, giải nén nhanh hơn nén
  • Có thể dùng pxz (parallel xz)

Khi nào dùng:

  • Cần file nhỏ nhất có thể
  • Lưu trữ dài hạn
  • Distribution packages (như .deb, .rpm)

1.6. 7Z (.7z)

Đặc điểm:

  • Định dạng của 7-Zip
  • Tỷ lệ nén rất cao, tương đương TAR.XZ
  • Hỗ trợ multi-threading native
  • Nén và giải nén nhanh hơn TAR.XZ
  • Hỗ trợ encryption mạnh (AES-256)

Khi nào dùng:

  • Cần tỷ lệ nén cao + tốc độ nhanh
  • Backup lớn trên VPS
  • Không cần chia sẻ với Windows (ít phổ biến)

1.7. ZST / ZSTD (.tar.zst)

Đặc điểm:

  • Compression algorithm mới của Facebook
  • Cân bằng tốt giữa tốc độ và tỷ lệ nén
  • Nhanh hơn GZIP, nén tốt hơn GZIP
  • Hỗ trợ multi-threading

Khi nào dùng:

  • Backup nhanh với tỷ lệ nén tốt
  • Modern Linux distributions (>= Ubuntu 18.04)
  • Production deployments

2. Benchmark Chi Tiết

2.1. Test Environment

  • Hardware: VPS 6 cores (Intel Xeon), 12GB RAM, NVMe SSD
  • Test Data: WordPress site – 2GB (files + database)
    • 50,000 files
    • Mix: PHP, images, CSS, JS, SQL dumps

2.2. Compression Benchmark

Format Nén (1 thread) Nén (6 threads) Kích thước Tỷ lệ nén
TAR (no compression) 12s N/A 2000 MB 0%
ZIP 180s N/A 850 MB 57.5%
TAR.GZ (gzip) 165s N/A 820 MB 59%
TAR.GZ (pigz) 165s 35s 820 MB 59%
TAR.BZ2 (bzip2) 380s N/A 720 MB 64%
TAR.BZ2 (pbzip2) 380s 75s 720 MB 64%
TAR.XZ (xz) 520s N/A 680 MB 66%
TAR.XZ (pxz) 520s 110s 680 MB 66%
7Z (7z -mx5) 240s 55s 700 MB 65%
7Z (7z -mx9) 450s 95s 650 MB 67.5%
TAR.ZST (zstd) 95s 22s 780 MB 61%

2.3. Decompression Benchmark

Format Giải nén (1 thread) Giải nén (6 threads) Tốc độ
TAR 15s N/A ⭐⭐⭐⭐⭐
ZIP 85s N/A ⭐⭐⭐
TAR.GZ (gzip) 65s N/A ⭐⭐⭐
TAR.GZ (pigz) 65s 18s ⭐⭐⭐⭐⭐
TAR.BZ2 (bzip2) 125s N/A ⭐⭐
TAR.BZ2 (pbzip2) 125s 28s ⭐⭐⭐⭐
TAR.XZ (xz) 95s N/A ⭐⭐⭐
TAR.XZ (pxz) 95s 25s ⭐⭐⭐⭐
7Z 72s 22s ⭐⭐⭐⭐⭐
TAR.ZST (zstd) 45s 12s ⭐⭐⭐⭐⭐+

2.4. Kết Luận Benchmark

Nén nhanh nhất: TAR.ZST (22s với 6 threads) Giải nén nhanh nhất: TAR.ZST (12s với 6 threads) Nén tốt nhất: TAR.XZ / 7Z -mx9 (~65-67%) Cân bằng nhất: TAR.ZST hoặc 7Z -mx5

3. So Sánh Chi Tiết

3.1. Tốc Độ Nén

Nhanh nhất → Chậm nhất:
TAR (uncompressed) > TAR.ZST > TAR.GZ (pigz) > 7Z (-mx5) > TAR.BZ2 (pbzip2) > TAR.XZ (pxz)

Khuyến nghị:

  • Backup hàng ngày: TAR.ZST hoặc TAR.GZ (pigz)
  • Không cần nén: TAR (nếu chỉ transfer nội bộ SSD)

3.2. Tốc Độ Giải Nén

Nhanh nhất → Chậm nhất:
TAR.ZST > TAR.GZ (pigz) > 7Z > TAR.BZ2 (pbzip2) > TAR.XZ (pxz)

Khuyến nghị:

  • Deployment thường xuyên: TAR.ZST hoặc TAR.GZ
  • One-time restore: Bất kỳ format nào cũng OK

3.3. Tỷ Lệ Nén

Tốt nhất → Tệ nhất:
7Z (-mx9) ≈ TAR.XZ > TAR.BZ2 > 7Z (-mx5) > TAR.GZ ≈ TAR.ZST > ZIP > TAR

Khuyến nghị:

  • Lưu trữ dài hạn: 7Z -mx9 hoặc TAR.XZ
  • Bandwidth giới hạn: TAR.BZ2 hoặc 7Z

3.4. CPU Usage

Format Single-thread Multi-thread Hiệu quả
ZIP 100% (1 core) N/A ⭐⭐
TAR.GZ (gzip) 100% (1 core) N/A ⭐⭐
TAR.GZ (pigz) N/A 600% (6 cores) ⭐⭐⭐⭐⭐
7Z N/A 600% (6 cores) ⭐⭐⭐⭐⭐
TAR.ZST N/A 600% (6 cores) ⭐⭐⭐⭐⭐

Khuyến nghị:

  • VPS multi-core: Luôn dùng parallel versions (pigz, pbzip2, pxz, zstd, 7z)

3.5. Compatibility

Format Linux Windows macOS Web
ZIP ✅ ✅ ✅ ✅
TAR ✅ ⚠️ ✅ ❌
TAR.GZ ✅ ⚠️ ✅ ❌
TAR.BZ2 ✅ ⚠️ ✅ ❌
TAR.XZ ✅ ⚠️ ✅ ❌
7Z ✅ ✅ ⚠️ ❌
TAR.ZST ✅ ⚠️ ⚠️ ❌

Khuyến nghị:

  • Linux-only: TAR.GZ, TAR.ZST, 7Z
  • Cross-platform: ZIP (nhưng kém hiệu quả nhất)

4. Hướng Dẫn Sử Dụng

4.1. TAR (Uncompressed)

# Nén
tar -cf archive.tar /path/to/directory

# Giải nén
tar -xf archive.tar

# Xem nội dung
tar -tf archive.tar

# Nén và hiển thị tiến trình
tar -cvf archive.tar /path/to/directory

Use case: Transfer nhanh giữa các SSD/NVMe trong cùng data center

4.2. TAR.GZ với PIGZ (Khuyến nghị)

# Cài đặt pigz
sudo apt install pigz -y

# Nén với multi-threading
tar -cf - /path/to/directory | pigz -p 6 > archive.tar.gz

# Hoặc dùng cách này
tar --use-compress-program="pigz -p 6" -cf archive.tar.gz /path/to/directory

# Giải nén với pigz
pigz -d -p 6 archive.tar.gz
tar -xf archive.tar

# Hoặc 1 lệnh
tar --use-compress-program="pigz -p 6" -xf archive.tar.gz

# Nén với compression level (1-9, default 6)
tar -cf - /path/to/directory | pigz -p 6 -9 > archive.tar.gz

4.3. TAR.BZ2 với PBZIP2

# Cài đặt pbzip2
sudo apt install pbzip2 -y

# Nén
tar -cf - /path/to/directory | pbzip2 -p6 > archive.tar.bz2

# Hoặc
tar --use-compress-program="pbzip2 -p6" -cf archive.tar.bz2 /path/to/directory

# Giải nén
pbzip2 -d -p6 archive.tar.bz2
tar -xf archive.tar

# Hoặc
tar --use-compress-program="pbzip2 -p6" -xf archive.tar.bz2

4.4. TAR.XZ với PXZ

# Cài đặt pxz (hoặc pixz)
sudo apt install pxz -y
# Hoặc
sudo apt install pixz -y

# Nén với pxz
tar -cf - /path/to/directory | pxz -T 6 > archive.tar.xz

# Nén với pixz (tốt hơn với file lớn)
tar -cf - /path/to/directory | pixz -p 6 > archive.tar.xz

# Giải nén
pxz -d archive.tar.xz
tar -xf archive.tar

# Hoặc dùng xz với multi-threading (xz >= 5.2)
tar -cf - /path/to/directory | xz -T 6 > archive.tar.xz

4.5. 7Z (Khuyến nghị cao)

# Cài đặt
# Ubuntu
sudo apt install p7zip-full -y

#Almalinux
sudo dnf install -y epel-release
sudo dnf install -y p7zip p7zip-plugins

# Nén với compression level 5 (cân bằng)
7z a -t7z -mx=5 -mmt=6 archive.7z /path/to/directory

# Nén với compression level 9 (tối đa)
7z a -t7z -mx=9 -mmt=6 archive.7z /path/to/directory

# Nén ultra (cực chậm, nén cực tốt)
7z a -t7z -mx=9 -m0=lzma2 -mmt=6 archive.7z /path/to/directory

# Giải nén
7z x archive.7z -mmt=6

# Nén với password
7z a -t7z -mx=5 -mmt=6 -p"your_password" archive.7z /path/to/directory

# Nén với encryption AES-256
7z a -t7z -mx=5 -mmt=6 -p"password" -mhe=on archive.7z /path/to/directory

4.6. TAR.ZST với ZSTD (Khuyến nghị cao nhất)

# Cài đặt zstd
sudo apt install zstd -y

# Nén (compression level 3, default)
tar -cf - /path/to/directory | zstd -T6 > archive.tar.zst

# Hoặc
tar --use-compress-program="zstd -T6" -cf archive.tar.zst /path/to/directory

# Nén với level cao hơn (1-19, default 3)
tar -cf - /path/to/directory | zstd -T6 -10 > archive.tar.zst

# Nén ultra (level 20-22, rất chậm)
tar -cf - /path/to/directory | zstd -T6 -22 > archive.tar.zst

# Giải nén
zstd -d -T6 archive.tar.zst
tar -xf archive.tar

# Hoặc
tar --use-compress-program="zstd -T6" -xf archive.tar.zst

4.7. ZIP (Khi cần compatibility)

# Cài đặt
sudo apt install zip -y

# Nén (không có multi-threading native)
zip -r archive.zip /path/to/directory

# Nén với compression level 9
zip -9 -r archive.zip /path/to/directory

# Nén với password
zip -P "password" -r archive.zip /path/to/directory

# Giải nén
unzip archive.zip

# Workaround cho multi-threading với ZIP (dùng 7z)
7z a -tzip -mx=9 -mmt=6 archive.zip /path/to/directory

5. Khuyến Nghị Chi Tiết Theo Use Case

5.1. Backup Hàng Ngày (Daily Backup)

Khuyến nghị: TAR.ZST hoặc TAR.GZ (pigz)

#!/bin/bash
# daily_backup.sh

BACKUP_DIR="/backup/daily"
SOURCE="/var/www"
DATE=$(date +%Y%m%d)
THREADS=$(nproc)

# Option 1: TAR.ZST (nhanh nhất, nén tốt)
tar --use-compress-program="zstd -T${THREADS}" \
    -cf "${BACKUP_DIR}/web_${DATE}.tar.zst" \
    "$SOURCE"

# Option 2: TAR.GZ với pigz (phổ biến hơn)
tar --use-compress-program="pigz -p ${THREADS}" \
    -cf "${BACKUP_DIR}/web_${DATE}.tar.gz" \
    "$SOURCE"

# Xóa backup cũ hơn 7 ngày
find "$BACKUP_DIR" -name "web_*.tar.*" -mtime +7 -delete

Tại sao?

  • Nén và giải nén nhanh nhất
  • Tỷ lệ nén tốt (60%)
  • Không làm gián đoạn server nhiều

5.2. Backup Tuần (Weekly Backup)

Khuyến nghị: 7Z -mx5 hoặc TAR.BZ2 (pbzip2)

#!/bin/bash
# weekly_backup.sh

BACKUP_DIR="/backup/weekly"
SOURCE="/var/www"
DATE=$(date +%Y_week%U)
THREADS=$(nproc)

# Option 1: 7Z (cân bằng tốt)
7z a -t7z -mx=5 -mmt=${THREADS} \
    "${BACKUP_DIR}/web_${DATE}.7z" \
    "$SOURCE"

# Option 2: TAR.BZ2 (tương thích tốt)
tar --use-compress-program="pbzip2 -p${THREADS}" \
    -cf "${BACKUP_DIR}/web_${DATE}.tar.bz2" \
    "$SOURCE"

# Xóa backup cũ hơn 4 tuần
find "$BACKUP_DIR" -name "web_*.7z" -mtime +28 -delete

Tại sao?

  • Nén tốt hơn daily backup (64-65%)
  • Chạy vào cuối tuần, có thể chậm hơn
  • Tiết kiệm disk space

5.3. Backup Tháng (Monthly Archive)

Khuyến nghị: 7Z -mx9 hoặc TAR.XZ

#!/bin/bash
# monthly_backup.sh

BACKUP_DIR="/backup/monthly"
SOURCE="/var/www"
DATE=$(date +%Y%m)
THREADS=$(nproc)

# Option 1: 7Z ultra compression
7z a -t7z -mx=9 -m0=lzma2 -mmt=${THREADS} \
    -mhe=on -p"your_strong_password" \
    "${BACKUP_DIR}/web_${DATE}.7z" \
    "$SOURCE"

# Option 2: TAR.XZ (standard)
tar --use-compress-program="pixz -p ${THREADS}" \
    -cf "${BACKUP_DIR}/web_${DATE}.tar.xz" \
    "$SOURCE"

# Giữ backup 12 tháng
find "$BACKUP_DIR" -name "web_*.7z" -mtime +365 -delete

Tại sao?

  • Nén tốt nhất (67-70%)
  • Lưu trữ dài hạn, không quan tâm tốc độ
  • Có thể encrypt để bảo mật

5.4. Transfer File Giữa Servers

Khuyến nghị: TAR.GZ (pigz) hoặc TAR.ZST

# Server A (source)
tar --use-compress-program="pigz -p 6" -cf - /path/to/data | \
    ssh user@server-b "cat > /path/to/backup.tar.gz"

# Hoặc với pv để hiển thị progress
tar --use-compress-program="pigz -p 6" -cf - /path/to/data | \
    pv | \
    ssh user@server-b "cat > /path/to/backup.tar.gz"

# Với ZSTD (nhanh hơn)
tar --use-compress-program="zstd -T6" -cf - /path/to/data | \
    ssh user@server-b "cat > /path/to/backup.tar.zst"

Tại sao?

  • Nén nhanh, giảm bandwidth
  • Transfer và nén song song
  • Hỗ trợ resume với rsync

5.5. Deploy Code (WordPress/Laravel/Node.js)

Khuyến nghị: TAR.GZ (pigz) hoặc ZIP

# Deployment script
RELEASE_DIR="/var/www/releases"
CURRENT_DIR="/var/www/current"
VERSION=$(git describe --tags)

# Nén release
cd /path/to/project
tar --use-compress-program="pigz -p 6" \
    --exclude='node_modules' \
    --exclude='.git' \
    -cf "${RELEASE_DIR}/release_${VERSION}.tar.gz" .

# Deploy
cd "$RELEASE_DIR"
mkdir -p "release_${VERSION}"
tar --use-compress-program="pigz -p 6" \
    -xf "release_${VERSION}.tar.gz" \
    -C "release_${VERSION}"

# Symlink
ln -sfn "${RELEASE_DIR}/release_${VERSION}" "$CURRENT_DIR"

Tại sao?

  • Nhanh
  • Giữ nguyên permissions
  • Standard cho Linux deployments

5.6. Database Backup

Khuyến nghị: GZIP hoặc ZSTD

# MySQL/MariaDB với GZIP
mysqldump --all-databases | pigz -p 6 > backup.sql.gz

# MySQL/MariaDB với ZSTD (nhanh hơn, nén tốt hơn)
mysqldump --all-databases | zstd -T6 > backup.sql.zst

# PostgreSQL
pg_dumpall | pigz -p 6 > backup.sql.gz

# MongoDB
mongodump --archive | pigz -p 6 > backup.archive.gz

Tại sao?

  • SQL là text, nén cực tốt (80-90%)
  • Streaming, không cần disk space tạm
  • Nhanh với pigz/zstd

5.7. Log Files Archive

Khuyến nghị: TAR.XZ hoặc 7Z -mx9

# Archive logs cũ
find /var/log -name "*.log" -mtime +30 | \
    tar --use-compress-program="xz -T6" -cf old_logs.tar.xz -T -

# Hoặc với 7z
find /var/log -name "*.log" -mtime +30 > /tmp/log_list.txt
7z a -t7z -mx=9 -mmt=6 old_logs.7z @/tmp/log_list.txt

Tại sao?

  • Log files là text, nén cực kỳ tốt
  • Không cần truy cập thường xuyên
  • Tiết kiệm disk space tối đa

6. Scripts Tự Động

6.1. Smart Compress Script

#!/bin/bash
# smart_compress.sh - Tự động chọn format tối ưu

SOURCE="$1"
DEST_NAME="${2:-archive}"
THREADS=$(nproc)

if [ -z "$SOURCE" ]; then
    echo "Cách dùng: $0 <source_path> [archive_name]"
    exit 1
fi

# Tính kích thước source
SOURCE_SIZE=$(du -sm "$SOURCE" | cut -f1)
echo "Kích thước source: ${SOURCE_SIZE}MB"

# Quyết định format dựa trên kích thước
if [ $SOURCE_SIZE -lt 500 ]; then
    # File nhỏ: dùng TAR.GZ (phổ biến)
    echo "File nhỏ - dùng TAR.GZ với pigz..."
    tar --use-compress-program="pigz -p ${THREADS}" \
        -cf "${DEST_NAME}.tar.gz" "$SOURCE"
    
elif [ $SOURCE_SIZE -lt 5000 ]; then
    # File trung bình: dùng TAR.ZST (nhanh + nén tốt)
    echo "File trung bình - dùng TAR.ZST..."
    tar --use-compress-program="zstd -T${THREADS}" \
        -cf "${DEST_NAME}.tar.zst" "$SOURCE"
    
else
    # File lớn: dùng 7Z (nén tốt nhất)
    echo "File lớn - dùng 7Z với mx=5..."
    7z a -t7z -mx=5 -mmt=${THREADS} \
        "${DEST_NAME}.7z" "$SOURCE"
fi

echo "Hoàn thành! Output:"
ls -lh "${DEST_NAME}."*

6.2. Multi-Format Compress (For Testing)

#!/bin/bash
# multi_compress.sh - Nén với nhiều format để so sánh

SOURCE="$1"
THREADS=$(nproc)

if [ -z "$SOURCE" ]; then
    echo "Cách dùng: $0 <source_path>"
    exit 1
fi

echo "Bắt đầu nén với nhiều format..."
echo "Source: $SOURCE"
echo "Threads: $THREADS"
echo ""

# TAR uncompressed
echo "1. TAR (uncompressed)..."
time tar -cf archive.tar "$SOURCE"

# TAR.GZ với pigz
echo "2. TAR.GZ với pigz..."
time tar --use-compress-program="pigz -p ${THREADS}" -cf archive.tar.gz "$SOURCE"

# TAR.BZ2 với pbzip2
echo "3. TAR.BZ2 với pbzip2..."
time tar --use-compress-program="pbzip2 -p${THREADS}" -cf archive.tar.bz2 "$SOURCE"

# TAR.XZ với pxz
echo "4. TAR.XZ với pxz..."
time tar -cf - "$SOURCE" | pxz -T ${THREADS} > archive.tar.xz

# 7Z -mx5
echo "5. 7Z (mx=5)..."
time 7z a -t7z -mx=5 -mmt=${THREADS} archive_mx5.7z "$SOURCE"

# 7Z -mx9
echo "6. 7Z (mx=9)..."
time 7z a -t7z -mx=9 -mmt=${THREADS} archive_mx9.7z "$SOURCE"

# TAR.ZST
echo "7. TAR.ZST với zstd..."
time tar --use-compress-program="zstd -T${THREADS}" -cf archive.tar.zst "$SOURCE"

# Kết quả
echo ""
echo "=== KẾT QUẢ ==="
ls -lh archive*

# Cleanup
# rm archive*

6.3. Backup Rotation Script

#!/bin/bash
# backup_rotation.sh - Backup với rotation policy

BACKUP_ROOT="/backup"
SOURCE="/var/www"
THREADS=$(nproc)
DATE=$(date +%Y%m%d)

# Daily backup (7 days retention)
DAILY_DIR="${BACKUP_ROOT}/daily"
mkdir -p "$DAILY_DIR"
tar --use-compress-program="zstd -T${THREADS}" \
    -cf "${DAILY_DIR}/backup_${DATE}.tar.zst" "$SOURCE"
find "$DAILY_DIR" -name "backup_*.tar.zst" -mtime +7 -delete

# Weekly backup (4 weeks retention) - chạy vào Chủ nhật
if [ $(date +%u) -eq 7 ]; then
    WEEKLY_DIR="${BACKUP_ROOT}/weekly"
    mkdir -p "$WEEKLY_DIR"
    WEEK=$(date +%Y_W%U)
    7z a -t7z -mx=5 -mmt=${THREADS} \
        "${WEEKLY_DIR}/backup_${WEEK}.7z" "$SOURCE"
    find "$WEEKLY_DIR" -name "backup_*.7z" -mtime +28 -delete
fi

# Monthly backup (12 months retention) - chạy vào ngày đầu tháng
if [ $(date +%d) -eq 01 ]; then
    MONTHLY_DIR="${BACKUP_ROOT}/monthly"
    mkdir -p "$MONTHLY_DIR"
    MONTH=$(date +%Y%m)
    7z a -t7z -mx=9 -mmt=${THREADS} \
        "${MONTHLY_DIR}/backup_${MONTH}.7z" "$SOURCE"
    find "$MONTHLY_DIR" -name "backup_*.7z" -mtime +365 -delete
fi

echo "Backup completed: $(date)"

7. Bảng Tra Cứu Nhanh

7.1. Decision Table

Mục đích Format Command Lý do
Backup hàng ngày TAR.ZST tar --use-compress-program="zstd -T6" Nhanh nhất, nén tốt
Backup tuần 7Z (-mx5) 7z a -t7z -mx=5 -mmt=6 Cân bằng tốt
Backup tháng 7Z (-mx9) 7z a -t7z -mx=9 -mmt=6 Nén tốt nhất
Transfer servers TAR.GZ tar + pigz Phổ biến, nhanh
Deploy code TAR.GZ tar + pigz Standard, giữ permissions
Database backup SQL.ZST mysqldump + zstd Nén cực tốt text
Log archive TAR.XZ tar + xz Nén tối đa
Share với Windows ZIP 7z a -tzip -mmt=6 Compatibility
Internal transfer TAR tar -cf Nhanh nhất (no compression)

7.2. Speed vs Compression

         Tốc độ nén
         ↑
    Fast │  TAR.ZST
         │  TAR.GZ (pigz)
         │  7Z (-mx1)
         │
  Medium │  7Z (-mx5)
         │  TAR.BZ2 (pbzip2)
         │
    Slow │  7Z (-mx9)
         │  TAR.XZ (pxz)
         │
         └─────────────────→ Tỷ lệ nén
           Low    Medium    High

7.3. Commands Cheat Sheet

# Cài đặt tools
sudo apt install pigz pbzip2 pxz pixz zstd p7zip-full -y

# TAR.GZ (Khuyến nghị cho general use)
tar --use-compress-program="pigz -p 6" -cf archive.tar.gz /path/to/dir

# TAR.ZST (Khuyến nghị cho VPS hiện đại)
tar --use-compress-program="zstd -T6" -cf archive.tar.zst /path/to/dir

# 7Z (Khuyến nghị cho backup quan trọng)
7z a -t7z -mx=5 -mmt=6 archive.7z /path/to/dir

# Giải nén universal
tar -xf archive.tar.*   # Auto-detect compression
7z x archive.*          # Hỗ trợ hầu hết formats

8. Performance Tips

8.1. Tối Ưu CPU

# Luôn dùng multi-threading
THREADS=$(nproc)

# Nếu server busy, giảm threads
THREADS=$(($(nproc) - 2))

# Hoặc dùng nice để giảm priority
nice -n 19 tar --use-compress-program="pigz -p 6" -cf archive.tar.gz /path

8.2. Tối Ưu I/O

# Dùng ionice để giảm impact
ionice -c 3 tar --use-compress-program="pigz -p 6" -cf archive.tar.gz /path

# Kết hợp nice + ionice
nice -n 19 ionice -c 3 7z a -t7z -mx=5 -mmt=6 archive.7z /path

8.3. Nén Trên RAM (Speed Boost)

# Cho file < 50% RAM
TMPDIR=/dev/shm tar --use-compress-program="pigz -p 6" -cf archive.tar.gz /path

# Hoặc tạo tmpfs riêng
sudo mount -t tmpfs -o size=4G tmpfs /mnt/ram
cd /mnt/ram
tar --use-compress-program="pigz -p 6" -cf archive.tar.gz /original/path
cp archive.tar.gz /destination/
sudo umount /mnt/ram

8.4. Exclude Patterns

# Exclude cache, logs, node_modules
tar --use-compress-program="pigz -p 6" \
    --exclude='*.log' \
    --exclude='node_modules' \
    --exclude='cache' \
    --exclude='.git' \
    -cf archive.tar.gz /var/www

# Với 7z
7z a -t7z -mx=5 -mmt=6 archive.7z /var/www \
    -xr!*.log -xr!node_modules -xr!cache -xr!.git

9. Troubleshooting

9.1. Compression Failed

# Kiểm tra disk space
df -h /destination/path

# Kiểm tra permissions
ls -la /source/path

# Test với file nhỏ trước
tar --use-compress-program="pigz -p 1" -cf test.tar.gz /small/sample

9.2. Out of Memory

# Giảm threads
tar --use-compress-program="pigz -p 2" -cf archive.tar.gz /path

# Hoặc dùng compression nhẹ hơn
tar --use-compress-program="pigz -p 6 -1" -cf archive.tar.gz /path

# Dùng swap nếu cần
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

9.3. Too Slow

# Check I/O
iostat -x 1

# Nếu I/O bottleneck, tăng threads không giúp
# Solution: Upgrade SSD hoặc dùng compression nhẹ hơn

# Check CPU
htop

# Nếu CPU < 100%, tăng threads
THREADS=$(($(nproc) * 2))

10. Kết Luận & Khuyến Nghị Cuối

10.1. Top 3 Khuyến Nghị Chung

1️⃣ TAR.ZSTD – Best for Modern VPS

tar --use-compress-program="zstd -T$(nproc)" -cf archive.tar.zst /path
  • ✅ Nhanh nhất (nén + giải nén)
  • ✅ Tỷ lệ nén tốt (60-65%)
  • ✅ Multi-threading native
  • ❌ Chưa phổ biến như TAR.GZ

2️⃣ TAR.GZ (với pigz) – Most Compatible

tar --use-compress-program="pigz -p $(nproc)" -cf archive.tar.gz /path
  • ✅ Phổ biến nhất
  • ✅ Nhanh với multi-threading
  • ✅ Compatible với mọi hệ thống
  • ❌ Tỷ lệ nén trung bình

3️⃣ 7Z – Best Compression

7z a -t7z -mx=5 -mmt=$(nproc) archive.7z /path
  • ✅ Tỷ lệ nén cao nhất
  • ✅ Multi-threading tốt
  • ✅ Hỗ trợ encryption
  • ❌ Ít phổ biến hơn

10.2. Decision Flowchart

┌─────────────────────────────────┐
│  Cần nén file gì?               │
└────────────┬────────────────────┘
             │
        ┌────▼────┐
        │ Use Case│
        └────┬────┘
             │
   ┌─────────┼─────────┬─────────┐
   │         │         │         │
   ▼         ▼         ▼         ▼
Daily   Weekly   Monthly  Transfer
Backup  Backup   Archive  Files
   │         │         │         │
   ▼         ▼         ▼         ▼
TAR.ZST  7Z(mx5)  7Z(mx9)  TAR.GZ

10.3. Final Tips

  1. Luôn dùng multi-threading trên VPS multi-core
  2. Test trước với file nhỏ
  3. Monitor resources trong quá trình nén
  4. Verify integrity sau khi nén (7z t, tar -tf)
  5. Document format bạn chọn (cho team biết)
  6. Backup trước khi thử nghiệm format mới
  7. Rotate backups để tránh đầy disk
  8. Encrypt sensitive data (7z -p hoặc gpg)

10.4. Bảng Tóm Tắt Cuối

Tiêu chí Format 1 Format 2 Format 3
Nhanh nhất TAR.ZST TAR.GZ (pigz) TAR
Nén tốt nhất 7Z (-mx9) TAR.XZ TAR.BZ2
Cân bằng nhất TAR.ZST 7Z (-mx5) TAR.GZ
Phổ biến nhất TAR.GZ ZIP TAR.BZ2
Cho production TAR.GZ TAR.ZST 7Z

11. Tài Liệu Tham Khảo

  • ZSTD: https://facebook.github.io/zstd/
  • 7-Zip: https://www.7-zip.org/
  • GNU Tar: https://www.gnu.org/software/tar/
  • Pigz: https://zlib.net/pigz/
  • Compression Benchmark: https://github.com/inikep/lzbench

Tác giả: AI và Vũ Trụ Số biên dịch chỉnh sửa
Cập nhật: November 2025
Version: 2.0

Hy vọng bài viết này giúp bạn chọn được format nén phù hợp cho VPS của mình!

Việc sử dụng SSH key (Secure Shell key) thay cho mật khẩu khi đăng nhập vào VPS là một phương pháp bảo mật được khuyên dùng rộng rãi.

Bài viết này sẽ giải thích chi tiết về SSH key theo cách dễ hiểu nhất cho người mới bắt đầu.

SSH Key là gì? – Giải thích bằng ví dụ thực tế

Để hiểu SSH key, hãy tưởng tượng VPS của bạn như một căn nhà cần bảo vệ:

🔑 Cách truyền thống – Dùng mật khẩu:
Giống như sử dụng khóa cửa điện tử với mã số (123456…).

Vấn đề nguy hại đặt ra là:

  • Kẻ gian có thể quan sát khi bạn bấm mã hoặc thử đoán mã
  • Hacker dùng công cụ tự động thử hàng triệu mật khẩu mỗi giây (brute force attack)
  • Mật khẩu có thể bị lộ qua keylogger, phishing email, hoặc bị nhân viên xem trộm

🗝️ Cách hiện đại – Dùng SSH Key:

Giống như sử dụng vân tay để mở cửa nên rất an toàn.

  • Mỗi người có vân tay độc nhất, không thể làm giả
  • Không ai có thể “đoán” được vân tay của bạn
  • Trên internet, SSH key sử dụng mã hóa 2048-4096 bit – gần như không thể phá vỡ

Tại sao nên chuyển sang SSH Key?

1. Bảo mật vượt trội:

Mật khẩu thông thường SSH Key
Có thể đoán được (123456, password123…) Không thể đoán – độ dài tương đương mật khẩu 600+ ký tự
Dễ bị lộ khi gõ (keylogger, camera) Không cần gõ gì cả
Phải nhớ hoặc lưu ở đâu đó File key lưu an toàn trong máy
Ai biết mật khẩu đều vào được Chỉ ai có file Private Key mới vào được
Dễ bị tấn công brute force Miễn dịch với brute force

2. Tiện lợi trong công việc:

  • Không cần nhớ mật khẩu phức tạp
  • Đăng nhập nhanh chóng, không cần gõ password
  • Dễ dàng tự động hóa (backup, deploy code, CI/CD)
  • Một key có thể dùng cho nhiều server

3. Ngăn chặn các cuộc tấn công phổ biến:

  • Botnet quét port 22 và thử mật khẩu tự động
  • Tấn công từ điển (dictionary attack)
  • Nhân viên datacenter truy cập trái phép

Cơ chế hoạt động của SSH Key

SSH Key hoạt động theo nguyên lý mã hóa bất đối xứng với 2 thành phần:

  1. Private Key (Khóa riêng): File bạn giữ trên máy tính – giống như chìa khóa trong túi của bạn
  2. Public Key (Khóa công khai): File upload lên VPS – giống như ổ khóa gắn trên cửa

→ Chỉ Private Key của bạn mới mở được Public Key này!

Khi bạn kết nối SSH, hệ thống sẽ:
1. VPS gửi một thử thách mã hóa bằng Public Key
2. Máy tính của bạn dùng Private Key để giải mã
3. Nếu giải mã thành công → Xác thực OK → Cho phép đăng nhập

Các thuật toán SSH Key phổ biến

Khi tạo SSH key, bạn có thể chọn thuật toán mã hóa phù hợp:

Thuật toán Độ dài Bảo mật Khuyến nghị
Ed25519 256 bit Xuất sắc ✅ Nên dùng – Nhanh, bảo mật cao nhất
RSA 2048-4096 bit Tốt ✅ Dùng khi Ed25519 không được hỗ trợ
ECDSA 256-521 bit Tốt ⚠️ Ít phổ biến hơn
DSA 1024 bit Kém ❌ Không dùng – Đã lỗi thời

💡 Lời khuyên: Ưu tiên dùng Ed25519. Nếu VPS cũ không hỗ trợ, dùng RSA 4096 bit.

Hướng dẫn tạo SSH Key từng bước

BƯỚC 1: Tạo cặp SSH Key trên máy tính

Trên Windows (dùng PowerShell):

# Mở PowerShell với quyền Admin và chạy lệnh:
ssh-keygen -t ed25519 -C "email@example.com"

# Hệ thống sẽ hỏi 3 câu:
# 1. Lưu key ở đâu? → Enter để dùng vị trí mặc định
# 2. Đặt passphrase (mật khẩu bảo vệ key)? → Nhập hoặc Enter để bỏ qua
# 3. Xác nhận passphrase → Nhập lại hoặc Enter

# Kết quả: 2 file được tạo trong C:\Users\TenBan\.ssh\
# - id_ed25519 (Private Key - GIỮ BÍ MẬT!)
# - id_ed25519.pub (Public Key - có thể chia sẻ)

Kết quả mẫu khi tạo thành công:

Generating public/private ed25519 key pair.
Enter file in which to save the key (C:\Users\vutruso/.ssh/id_ed25519): [Enter]
Enter passphrase (empty for no passphrase): [Nhập mật khẩu hoặc Enter]
Enter same passphrase again: [Nhập lại hoặc Enter]
Your identification has been saved in C:\Users\vutruso/.ssh/id_ed25519
Your public key has been saved in C:\Users\vutruso/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:OQQw+PmFVcIN+IkvbZuJNfyPGAe19pCwCUxnhSuNY3k email@example.com

Trên Mac/Linux (dùng Terminal):

# Mở Terminal và chạy:
ssh-keygen -t ed25519 -C "email@example.com"

# Làm tương tự như Windows
# File được lưu trong ~/.ssh/

📝 Lưu ý về lệnh tạo key:

  • Nếu dùng ssh-keygen không tham số → Tạo RSA 3072 bit (mặc định)
  • -t ed25519: Chọn thuật toán Ed25519 (khuyến nghị)
  • -C "email": Thêm comment để dễ nhận diện key
  • Nếu VPS không hỗ trợ Ed25519, dùng: ssh-keygen -t rsa -b 4096

BƯỚC 2: Copy Public Key lên VPS

Trước tiên, xem nội dung Public Key:

# Windows:
type C:\Users\TenBan\.ssh\id_ed25519.pub

# Mac/Linux:
cat ~/.ssh/id_ed25519.pub

Copy toàn bộ dòng bắt đầu bằng ssh-ed25519... hoặc ssh-rsa...

Cách 1: Upload thủ công (universal – mọi hệ điều hành)

# Đăng nhập VPS bằng mật khẩu (lần cuối!)
ssh root@ip-vps-cua-ban

# Tạo thư mục .ssh nếu chưa có
mkdir -p ~/.ssh

# Thêm Public Key vào file authorized_keys
nano ~/.ssh/authorized_keys

# Paste Public Key vào (chuột phải hoặc Shift+Insert)
# Lưu: Ctrl+X → Y → Enter

# QUAN TRỌNG: Phân quyền đúng
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Hoặc bạn cũng có thể upload thủ công thông qua FTP/SFTP nhé.

Cách 2: Tự động với ssh-copy-id (Mac/Linux)

# Một lệnh duy nhất
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@ip-vps-cua-ban

# Nhập mật khẩu khi được hỏi

BƯỚC 3: Test kết nối với SSH Key

# Thoát khỏi VPS nếu đang ở trong
exit

# Test đăng nhập bằng key
ssh root@ip-vps-cua-ban

# Nếu thành công: Vào được không cần mật khẩu
# Nếu thất bại: Xem phần xử lý lỗi bên dưới

BƯỚC 4: Tăng cường bảo mật (Khuyến nghị)

Sau khi đã test thành công, tắt đăng nhập bằng mật khẩu:

# Sửa file cấu hình SSH
sudo nano /etc/ssh/sshd_config

Tìm và sửa các dòng sau


# Khong cho dang nhap bang mat khau
PasswordAuthentication no 
# Bat dang nhap bang ssh key
PubkeyAuthentication yes
ChallengeResponseAuthentication no

# Lưu và khởi động lại SSH
sudo systemctl restart sshd

# Hoặc trên server cũ:
sudo service ssh restart

Các định dạng SSH Key và vấn đề tương thích

Tùy phần mềm SSH client bạn dùng, định dạng key có thể khác nhau:

Bảng tương thích phần mềm

Phần mềm Hệ điều hành Định dạng key Ghi chú
OpenSSH Linux, Mac, Git Bash OpenSSH (mặc định) Phổ biến nhất
PuTTY Windows PPK Cần convert từ OpenSSH
Bitvise Windows OpenSSH, SSH2 Hỗ trợ nhiều định dạng
WinSCP Windows PPK Dùng chung với PuTTY
MobaXterm Windows OpenSSH, PPK Linh hoạt

Nhận biết các định dạng key

OpenSSH Format (phổ biến nhất):

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABl...
-----END OPENSSH PRIVATE KEY-----

PPK Format (PuTTY):

PuTTY-User-Key-File-2: ssh-rsa
Encryption: none
Comment: rsa-key-20240101
Public-Lines: 6
AAAAB3NzaC1yc2EAAAABJQAAAQEAw5sfqIpC2qm3i9gFmFKw7HtDCLmv7HVI...

SSH2 Format (Bitvise):

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "user@hostname"
AAAAB3NzaC1yc2EAAAABJQAAAQEAw5sfqIpC2qm3i9gFmFKw7HtDCLmv7HVI...
---- END SSH2 PUBLIC KEY ----

Chuyển đổi giữa các định dạng

OpenSSH → PPK (cho PuTTY):

  1. Mở PuTTYgen
  2. File → Load private key → Chọn file OpenSSH
  3. Save private key → Lưu thành .ppk

PPK → OpenSSH:

  1. Mở PuTTYgen
  2. Load file .ppk
  3. Conversions → Export OpenSSH key

Dòng lệnh chuyển đổi:

# PPK → OpenSSH
puttygen key.ppk -O private-openssh -o id_rsa
puttygen key.ppk -O public-openssh -o id_rsa.pub

# SSH2 → OpenSSH
ssh-keygen -i -f ssh2_key.pub > openssh_key.pub

# OpenSSH → SSH2  
ssh-keygen -e -f openssh_key.pub > ssh2_key.pub

Xử lý các lỗi thường gặp

🔴 Lỗi: “Server refused our key”

Nguyên nhân: Quyền file không đúng hoặc sai định dạng key

Cách khắc phục:

# Kiểm tra quyền file trên VPS
ls -la ~/.ssh/

# Đảm bảo quyền đúng:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

# Kiểm tra owner
chown -R $USER:$USER ~/.ssh

🔴 Lỗi: “Permission denied (publickey)”

Nguyên nhân: Sử dụng sai key hoặc key không tồn tại

Cách khắc phục:

# Xem SSH đang dùng key nào
ssh -vv root@ip-vps-cua-ban

# Chỉ định key cụ thể
ssh -i ~/.ssh/id_ed25519 root@ip-vps-cua-ban

# Windows
ssh -i C:\Users\TenBan\.ssh\id_ed25519 root@ip-vps-cua-ban

🔴 Lỗi: Public Key format không đúng

Sai: Copy thiếu hoặc xuống dòng

ssh-rsa AAAAB3NzaC1yc2EA...
...tiếp tục dòng 2

Đúng: Một dòng duy nhất

ssh-rsa AAAAB3NzaC1yc2EA...xyz email@example.com

🔴 Lỗi: Bitvise/PuTTY không nhận key

Giải pháp: Convert sang định dạng phù hợp (xem phần chuyển đổi ở trên)

Checklist khắc phục lỗi

Bạn check xem có vượt qua các lỗi sau không nhé.

  1. Kiểm tra định dạng key đúng với phần mềm đang dùng
  2. Đảm bảo quyền file: 700 cho ~/.ssh và 600 cho authorized_keys
  3. Public key phải nằm trên 1 dòng duy nhất
  4. Không có ký tự lạ hoặc space thừa trong key
  5. Test với verbose mode: ssh -vvv user@host

Câu hỏi thường gặp (FAQ)

❓ Nếu mất Private Key thì sao?
→ Không thể khôi phục! Như mất chìa khóa nhà vậy. Luôn backup Private Key ở nơi an toàn (USB, cloud mã hóa).

❓ Một SSH key có thể dùng cho bao nhiêu VPS?
→ Không giới hạn! Copy Public Key lên bao nhiêu server tùy ý. Như một chìa khóa mở được nhiều cửa.

❓ Có nên tạo nhiều SSH key không?
→ Nên! Mỗi máy tính/thiết bị nên có key riêng. Dễ quản lý và thu hồi quyền truy cập khi cần.

❓ Passphrase là gì? Có cần thiết không?
→ Là mật khẩu bảo vệ Private Key – lớp bảo mật thứ 2. Rất cần thiết cho laptop/máy dùng chung.

❓ SSH key có hết hạn không?
→ Không tự hết hạn. Nhưng nên rotate (đổi key mới) định kỳ 6-12 tháng để tăng bảo mật.

❓ Có thể khôi phục VPS nếu tắt password login mà mất key?
→ Phải liên hệ provider VPS để reset qua console hoặc rescue mode. Luôn test kỹ trước khi tắt password!

Các biện pháp bảo mật bổ sung

Sau khi setup SSH key, tăng cường bảo mật thêm:

  1. Đổi port SSH mặc định (22): 
    # Sửa trong /etc/ssh/sshd_config
Port 2222
  2. Cài đặt Fail2Ban: Tự động block IP đăng nhập sai nhiều lần
  3. Firewall rules: Chỉ cho phép IP cụ thể kết nối SSH
  4. Disable root login: Tạo user sudo thay vì dùng root
  5. 2FA Authentication: Thêm Google Authenticator cho SSH

Tổng kết

SSH Key không chỉ an toàn hơn mật khẩu rất nhiều mà còn tiện lợi hơn trong công việc hàng ngày.

Ban đầu tiếp cận có vẻ phức tạp nhưng một khi đã setup xong, bạn sẽ không muốn quay lại dùng mật khẩu nữa!

Checklist triển khai SSH Key:

  1. Tạo SSH key pair (Ed25519 hoặc RSA 4096)
  2. Upload Public Key lên VPS
  3. Test kết nối thành công
  4. Backup Private Key
  5. Tắt password authentication
  6. Setup thêm các biện pháp bảo mật

Chúc bạn triển khai SSH Key thành công!

AlmaLinux là một hệ điều hành doanh nghiệp mã nguồn mở tương thích với RHEL (Red Hat Enterprise Linux), và việc đọc log hệ thống là một kỹ năng quan trọng để khắc phục sự cố và giám sát hiệu suất. Dưới đây là hướng dẫn chi tiết về cách đọc, phân tích và quản lý log trên AlmaLinux.

1. Vị trí của các file log chính

Trên AlmaLinux, hầu hết các file log được lưu trữ trong thư mục /var/log. Một số file log quan trọng bao gồm:

  • /var/log/messages: Log chung của hệ thống
  • /var/log/secure: Log liên quan đến bảo mật và xác thực
  • /var/log/dmesg: Log khởi động hệ thống
  • /var/log/boot.log: Log quá trình khởi động
  • /var/log/cron: Log của các tác vụ cron
  • /var/log/maillog: Log của dịch vụ mail
  • /var/log/httpd/: Thư mục chứa log của Apache (nếu được cài đặt)
  • /var/log/audit/audit.log: Log kiểm tra hệ thống
  • /var/log/journal/: Thư mục chứa journald logs (định dạng nhị phân)

2. Các công cụ đọc log

a) Lệnh cat, less, tail, grep

# Xem toàn bộ file log
cat /var/log/messages

# Xem file log với khả năng cuộn
less /var/log/messages

# Xem 10 dòng cuối cùng của file log
tail /var/log/messages

# Theo dõi log theo thời gian thực
tail -f /var/log/messages

# Lọc log theo từ khóa
grep "error" /var/log/messages

b) Sử dụng journalctl

AlmaLinux sử dụng systemd, do đó bạn có thể sử dụng journalctl để đọc log:

# Xem tất cả log
journalctl

# Xem log từ lần khởi động gần nhất
journalctl -b

# Xem log của một dịch vụ cụ thể
journalctl -u httpd.service

# Xem log theo thời gian thực
journalctl -f

# Lọc log theo mức độ nghiêm trọng
journalctl -p err..emerg

# Xem log trong khoảng thời gian cụ thể
journalctl --since "2023-01-01" --until "2023-01-02"

# Xem log theo định dạng JSON
journalctl -o json

3. Phân tích log để phát hiện vấn đề

a) Các mức độ nghiêm trọng trong log

Log hệ thống thường được phân loại theo mức độ nghiêm trọng:

  • EMERG: Hệ thống không thể sử dụng được
  • ALERT: Cần hành động ngay lập tức
  • CRIT: Các điều kiện nguy hiểm
  • ERR: Lỗi
  • WARNING: Cảnh báo
  • NOTICE: Thông báo bình thường nhưng quan trọng
  • INFO: Thông tin
  • DEBUG: Thông tin gỡ lỗi

Để tìm các vấn đề nghiêm trọng:

grep -i "error\|warn\|fail\|crit" /var/log/messages
journalctl -p err..emerg

b) Các vấn đề thường gặp và cách nhận biết

Vấn đề đăng nhập và bảo mật

# Kiểm tra các lần đăng nhập thất bại
grep "Failed password" /var/log/secure

# Kiểm tra các lần đăng nhập thành công
grep "Accepted password" /var/log/secure

# Kiểm tra các nỗ lực đăng nhập SSH bất thường
grep "sshd" /var/log/secure | grep -i "fail\|invalid\|error"

# Thống kê IP đang cố gắng đăng nhập SSH
grep "Failed password" /var/log/secure | awk '{print $11}' | sort | uniq -c | sort -nr

Vấn đề về phần cứng

# Kiểm tra lỗi ổ đĩa
grep -i "error\|fail" /var/log/messages | grep -i "sd[a-z]"

# Kiểm tra vấn đề RAM
grep -i "memory" /var/log/messages

# Kiểm tra lỗi CPU
grep -i "cpu" /var/log/messages | grep -i "error"

# Kiểm tra nhiệt độ quá nóng
journalctl | grep -i "thermal\|temperature\|overheating"

Vấn đề về dịch vụ

# Kiểm tra các dịch vụ bị lỗi
systemctl --failed

# Xem log của dịch vụ Apache
journalctl -u httpd.service | grep -i error

# Xem log của MySQL/MariaDB
journalctl -u mariadb.service | grep -i error

# Kiểm tra các dịch vụ tự động khởi động
systemctl list-unit-files | grep enabled

Vấn đề về mạng

# Kiểm tra vấn đề mạng
grep -i "network\|eth\|ens\|wlan" /var/log/messages | grep -i "error\|fail\|down"

# Kiểm tra FirewallD
journalctl -u firewalld | grep -i "reject\|drop"

# Kiểm tra kết nối DNS
journalctl | grep -i "dns\|resolve\|nameserver" | grep -i "fail\|error"

4. Giám sát log theo thời gian thực

Để theo dõi log theo thời gian thực và phát hiện vấn đề kịp thời:

# Theo dõi nhiều file log cùng lúc
tail -f /var/log/messages /var/log/secure /var/log/httpd/error_log

# Sử dụng multitail (cần cài đặt)
dnf install multitail
multitail /var/log/messages /var/log/secure

# Theo dõi journald theo thời gian thực với bộ lọc
journalctl -f -u httpd.service -u mariadb.service

5. Quản lý kích thước và dung lượng log systemd journal

Journald logs không được quản lý có thể nhanh chóng chiếm dụng dung lượng đĩa, ảnh hưởng đến hiệu suất hệ thống. Dưới đây là cách quản lý dung lượng của systemd journal:

a) Kiểm tra dung lượng hiện tại của journal

# Xem dung lượng hiện tại của journal
journalctl --disk-usage

# Xem chi tiết các file journal
ls -lh /var/log/journal/

b) Cấu hình giới hạn kích thước journal

Chỉnh sửa file cấu hình journald:

vi /etc/systemd/journald.conf

Thêm hoặc chỉnh sửa các dòng sau để thiết lập giới hạn kích thước:

[Journal]
SystemMaxUse=256M      # Kích thước tối đa của journal
RuntimeMaxUse=128M     # Kích thước tối đa của journal trong bộ nhớ tạm
MaxFileSec=1month      # Thời gian tối đa để lưu giữ file log
MaxRetentionSec=1month # Thời gian tối đa để giữ các mục nhật ký

Các tùy chọn cấu hình quan trọng khác:

Storage=auto           # auto, persistent, volatile, or none
Compress=yes           # Nén dữ liệu log
ForwardToSyslog=yes    # Chuyển tiếp đến syslog

c) Xác minh cấu hình

# Xem cấu hình hiện tại
systemd-analyze cat-config systemd/journald.conf

d) Áp dụng thay đổi

# Khởi động lại dịch vụ journald
systemctl restart systemd-journald

e) Xóa journal cũ theo cách thủ công

# Xóa journal cũ hơn X ngày
journalctl --vacuum-time=7d

# Xóa journal để giới hạn kích thước
journalctl --vacuum-size=100M

# Xóa tất cả journal cũ
journalctl --rotate
journalctl --vacuum-time=1s

f) Kiểm tra lại dung lượng sau khi thay đổi

journalctl --disk-usage

6. Log forwarding và centralized logging

Đối với hệ thống quan trọng, nên chuyển tiếp log đến một máy chủ log tập trung:

a) Cấu hình chuyển tiếp log với rsyslog

# Cài đặt rsyslog nếu chưa có
dnf install rsyslog

# Chỉnh sửa file cấu hình
vi /etc/rsyslog.conf

# Thêm cấu hình chuyển tiếp (thay thế log_server bằng IP máy chủ log)
*.* @log_server:514         # UDP
*.* @@log_server:514        # TCP

# Khởi động lại dịch vụ
systemctl restart rsyslog

b) Sử dụng systemd-journal-remote

# Cài đặt systemd-journal-remote
dnf install systemd-journal-remote

# Cấu hình để gửi log
vi /etc/systemd/journal-upload.conf

# Thêm URL máy chủ đích
[Upload]
URL=https://log-server:19532

# Khởi động dịch vụ
systemctl enable --now systemd-journal-upload

7. Công cụ phân tích log nâng cao

a) LogWatch

LogWatch là công cụ phân tích log tự động và gửi báo cáo:

# Cài đặt LogWatch
dnf install logwatch

# Chạy LogWatch và xem báo cáo
logwatch --output stdout --format text --range today

# Cấu hình LogWatch để gửi báo cáo qua email
vi /etc/logwatch/conf/logwatch.conf

b) Giải pháp log tập trung và phân tích

Đối với môi trường lớn, bạn có thể cân nhắc sử dụng các giải pháp như:

  • Graylog: Nền tảng quản lý log tập trung với khả năng tìm kiếm mạnh mẽ
  • ELK Stack: Elasticsearch (lưu trữ), Logstash (xử lý), Kibana (hiển thị)
  • Prometheus + Grafana: Giám sát và hiển thị dữ liệu log theo thời gian thực
  • Loki + Grafana: Giải pháp nhẹ cho việc tập trung log và truy vấn

c) Tự động hóa giám sát log

# Tạo script kiểm tra log định kỳ
vi /etc/cron.hourly/check_critical_logs

# Nội dung script
#!/bin/bash
grep -i "error\|fail\|crit" /var/log/messages | tail -n 20 | mail -s "Critical log alerts" admin@example.com

# Thêm quyền thực thi
chmod +x /etc/cron.hourly/check_critical_logs

8. Xử lý log

a) Xoay vòng log truyền thống với logrotate

AlmaLinux sử dụng logrotate để quản lý kích thước và lưu trữ log truyền thống (file text):

# Xem cấu hình logrotate
cat /etc/logrotate.conf

# Xem cấu hình log cụ thể
ls -l /etc/logrotate.d/

# Tạo cấu hình xoay vòng tùy chỉnh cho ứng dụng
vi /etc/logrotate.d/myapp

# Ví dụ cấu hình
/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640 myapp myapp
    postrotate
        systemctl reload myapp
    endscript
}

b) Lưu trữ log lâu dài

# Nén log cũ
gzip /var/log/messages.1

# Lưu trữ log vào vị trí khác
mkdir -p /backup/logs
cp /var/log/messages.* /backup/logs/

# Lưu trữ journal logs
journalctl --since "2023-01-01" --until "2023-01-31" > /backup/logs/journal-jan-2023.log

9. Các trường hợp thực tế

Trường hợp 1: Hệ thống khởi động chậm

# Phân tích thời gian khởi động
systemd-analyze

# Phân tích chi tiết
systemd-analyze blame

# Kiểm tra log khởi động
journalctl -b | grep -i "slow\|timeout\|fail"

# Tìm các dịch vụ chạy lâu nhất khi khởi động
systemd-analyze critical-chain

Trường hợp 2: Máy chủ web gặp sự cố

# Kiểm tra log Apache
tail -n 100 /var/log/httpd/error_log

# Kiểm tra log truy cập
tail -n 100 /var/log/httpd/access_log | grep " 5[0-9][0-9] "

# Kiểm tra tình trạng dịch vụ
systemctl status httpd

# Kiểm tra tài nguyên hệ thống
journalctl -u httpd.service | grep -i "resource\|memory\|cpu"

Trường hợp 3: Vấn đề bảo mật

# Kiểm tra các IP đang cố gắng đăng nhập SSH
grep "Failed password" /var/log/secure | awk '{print $11}' | sort | uniq -c | sort -nr

# Kiểm tra tài khoản đăng nhập bất thường
grep "session opened" /var/log/secure | tail -n 20

# Kiểm tra các thay đổi quyền sudo
journalctl | grep -i "sudo\|su\|root"

# Kiểm tra cảnh báo từ auditd
ausearch -m AVC -ts today

Trường hợp 4: Disk Space đầy

# Kiểm tra dung lượng đĩa
df -h

# Tìm các file lớn
du -h --max-depth=1 /var | sort -hr

# Kiểm tra log cảnh báo không gian đĩa
journalctl | grep -i "disk space\|no space\|filesystem full"

# Kiểm tra inode
df -i

Trường hợp 5: Troubleshooting khi journald gặp sự cố

# Kiểm tra trạng thái journald
systemctl status systemd-journald

# Xóa journal để giải phóng không gian
journalctl --vacuum-time=1d

# Tạo thư mục log persistent nếu chưa tồn tại
mkdir -p /var/log/journal

# Đặt quyền thích hợp
chown root:systemd-journal /var/log/journal
chmod 2755 /var/log/journal

10. Mẹo và thủ thuật nâng cao

a) Tùy chỉnh định dạng đầu ra của journalctl

# Đầu ra ngắn gọn
journalctl --no-pager -o short

# Đầu ra chi tiết hơn
journalctl -o verbose

# Đầu ra định dạng JSON
journalctl -o json

# Chỉ hiển thị thông điệp
journalctl -o cat

b) Theo dõi hiệu suất dịch vụ qua log

# Đếm số lỗi theo giờ
journalctl -u httpd --since today | grep -i error | awk '{print $1, $2, $3}' | uniq -c

# Xem thời gian phản hồi trung bình từ log web
grep -r "request_time" /var/log/nginx/ | awk '{sum+=$10; count++} END {print sum/count}'

c) Tạo dashboard hiển thị log theo thời gian thực

# Sử dụng watch và journalctl
watch -n 1 'journalctl -u httpd.service --since "1 minute ago" | tail -n 10'

Kết luận

Đọc, phân tích và quản lý log hệ thống trên AlmaLinux là một kỹ năng quan trọng giúp phát hiện và khắc phục vấn đề một cách chủ động. Với việc sử dụng systemd journal, bạn có thêm các công cụ mạnh mẽ để quản lý log, nhưng cũng cần chú ý đến việc kiểm soát dung lượng để tránh tình trạng log chiếm quá nhiều không gian đĩa.

Quản lý log hiệu quả không chỉ giúp giải quyết sự cố nhanh chóng mà còn góp phần duy trì hiệu suất hệ thống ổn định theo thời gian. Hãy thiết lập một kế hoạch quản lý log định kỳ, bao gồm cả việc cấu hình giới hạn kích thước, xoay vòng log, và lưu trữ log quan trọng để đảm bảo an toàn dữ liệu và tuân thủ các yêu cầu về lưu trữ.

Thuật ngữ VPS hay máy chủ ảo có lẽ bạn đã từng một lần nghe qua, nhưng bạn có hiểu rõ nó là gì và cấu trúc máy chủ và phân chia nó ra sao hay không, trong bài viết này cùng Vũ Trụ Số tìm hiểu về VPS nhé.

VPS là gì?

VPS là tên viết tắt của Virtual private server. Đây là định nghĩa chính thức do IBM đặt ra:

“VPS, hay máy chủ ảo, là một dạng lưu trữ đám mây cho nhiều người thuê, trong đó tài nguyên máy chủ ảo hóa được cung cấp cho người dùng cuối qua internet thông qua đám mây hoặc nhà cung cấp dịch vụ lưu trữ”.

Thuật ngữ cũng khá rõ ràng tuy nhiên để dễ hình dung bạn tưởng tượng có 1 máy chủ vật lý: Từ máy chủ vậy lý này sẽ sử dụng các công nghệ ảo hóa và phân chia thành nhiều máy chủ ảo khác nhau, tất nhiên các máy chủ ảo này được máy chủ vật lý phân chia tài nguyên và VPS có 1 sức mạnh riêng tùy thuộc vào bộ nhớ ram, ổ cứng, cpu được chia.

  • Máy chủ là một máy tính được kết nối với internet và có thể lưu trữ các chương trình và trang web
  • Máy chủ ảo là một máy chủ ảo, chạy trên một máy tính thực và mang tính chuyên chuyên dụng. Thông thường, nhiều máy chủ ảo chạy trên một máy tính thực.
  • Nhiều người thuê có nghĩa là nhiều người có thể truy cập tài khoản của họ trên cùng một máy tính thực mà chúng ta đã nói đến. Trong trường hợp này, dưới dạng một máy chủ ảo. Tuy nhiên, tất cả các tài khoản này đều bị chia quyền rõ ràng và độc lập với nhau.
  • Nhà cung cấp dịch vụ lưu trữ hoặc đám mây là một công ty về cơ bản bán dịch vụ lưu trữ web. Lưu trữ web cũng giống như thuê một máy tính được kết nối với internet. Và máy chủ lưu trữ VPS đang thuê một máy chủ riêng ảo.

Đặc điểm của VPS

VPS có một số đặc điểm nhất định như sâu

  • Nó có một bộ nhớ nhất định, có thể được sử dụng để lưu trữ các trang web
  • Nó băng thông hàng tháng
  • Có dung lượng RAM cụ thể (tính bằng GB) và core CPU. Điều này phản ánh số lượng tính toán mà VPS có thể thực hiện và kết quả là nó có thể xử lý bao nhiêu khách truy cập.
  • Cuối cùng, giá cả thường là theo tháng hoặc thậm chí theo giờ.

VPS được sử dụng để làm gì?

VPS rất linh hoạt trong việc sử dụng nhưng thường được sử dụng cho webhosting là chính.

Bên cạnh việc lưu trữ các trang web, VPS cũng có thể có các công dụng như:

  • Tính toán và xử lý dữ liệu
  • Lưu trữ các API Rest và GraphQL; công nghệ được sử dụng để chạy các ứng dụng
  • Lưu trữ tệp và dữ liệu
  • Hoạt động như một bộ cân bằng tải, hướng lưu lượng truy cập đến các máy chủ khác
  • Chạy như một máy chủ cơ sở dữ liệu, chỉ phục vụ dữ liệu được lưu trữ trên một cơ sở dữ liệu
  • Chạy như một máy chủ tìm kiếm, cung cấp khả năng tìm kiếm nhanh các ứng dụng

Một VPS vs shared hosting, Cloud và dedicated hosting

VPS thường là một bước tiến so với shared hosting và VPS được sử dụng các tài nguyên độc lập và mạnh hơn rất nhiều so với shared hosting.

VPS có một lượng tài nguyên cố định (với một mức giá cố định) mà bạn thường có thể mở rộng quy mô theo cách thủ công hoặc tự động tùy thuộc vào stack cung cấp độ linh hoạt. Cloud hosting có số lượng tài nguyên có thể mở rộng có thể xử lý lượng khách truy cập cao dễ dàng hơn. Với dịch vụ lưu trữ đám mây, bạn chỉ cần trả tiền cho các tài nguyên bạn sử dụng mà thôi.

Tiêu chí

Shared Hosting

VPS

Dedicated Sever

Cloud Server

Định Nghĩa

Dịch vụ lưu trữ web, nơi chứa đồng thời nhiều trang web trên một máy chủ web được kết nối Internet.

Được tạo thành bằng phương pháp sử dụng công nghệ ảo hóa để chia tách từ một máy chủ riêng vật lý thành nhiều máy chủ ảo khác nhau.

Là máy chủ vật lý chạy trên phần cứng và các thiết bị hỗ trợ riêng biệt như HDD, CPU, RAM, Card mạng..

Cloud Server là việc ảo hóa các tài nguyên tính toán và các ứng dụng, cung cấp cho bạn một khả năng không giới hạn để xử lý các lưu lượng truy cập lớn.

Tài Nguyên

Shared hosting chia sẻ tài nguyên trên một máy chủ vật lý cho nhiều tài khoản shared hosting khác. Dễ bị giới hạn về tài nguyên, bảo mật thấp.

Các máy chủ ảo có tính năng tương tự như một máy chủ riêng, nhưng chạy chia sẻ tài nguyên từ máy chủ vật lý gốc.

Tài nguyên của máy chủ riêng riêng biệt, độc lập, không chia sẻ với bất kỳ ai.

Tài nguyên được ảo hóa thông qua môi trường Internet. Tính sẵn sàng cao, sử dụng các tài nguyên tính toán động.

Hiệu Năng

Hiệu suất vừa đủ cho cá nhân và doanh nghiệp nhỏ. Người dùng không có quyền truy cập sâu vào hệ thống, bị hạn chế khi website của bạn có lượng truy cập lớn, và hiệu suất website của bạn có thể bị ảnh hưởng bởi các trang web khác trên cùng một máy chủ.

VPS được khởi tạo và chạy trên một máy chủ vật lý. Vào thời gian cao điểm máy chủ vật lý có thể treo dẫn đến các VPS có thể tạm ngưng hoạt động.

Hiệu suất cao, an toàn, email ổn định, toàn quyền quản trị. Việc triển khai backup tốn nhiều chi phí.

Data được lưu trữ tập trung trên hệ thông Cloud Storage, I/O được phân bổ đều trên các Server. Data được backup và sẵn sàng phục hồi. Nếu có 1 Server vật lý bị lỗi, Cloud Server của bạn vẫn hoạt động ổn định nhờ cơ chế đồng bộ dữ liệu.

Khả Năng Mở Rộng

Khả năng mở rộng hạn chế vì phải chi sẻ tài nguyên máy chủ với nhiều shared hosting khác. Các website lớn dùng vượt mức tài nguyên mà shared hosting, tài khoản của bạn sẽ bị khóa nếu server quá tải.

Có thể nâng cấp tài nguyên phụ thuộc vào lượng tài nguyên còn lại của server vật lý. Nếu nâng quá nhiều thì server vật lý sẽ không đủ tài nguyên cung cấp.

Nâng cấp phức tạp vì phải mua thiết bị phần cứng chuyên dụng. Server có thể bị downtime khi nâng cấp.

Có khả năng nâng cấp và hạ cấp linh hoạt khi nhu cầu sử dụng thay đổi.

Quản Trị

Không quá khó khăn để quản lí được dịch vụ này, nó không đòi hỏi bạn phải có quá nhiều kiến thức liên quan.

Người dùng có toàn quyền quản trị máy chủ ảo tương tự như một máy chủ vật lý. Điều này yêu cầu người dùng phải có kỹ năng quản trị.

Người dùng toàn quyền quản trị máy chủ, có quyền cài đặt và cấu hình theo ý muốn.

Yêu cầu người dùng có kiến thức và kỹ năng quản trị máy chủ ảo.

Chi Phí

Đây thường là lựa chọn tiết kiệm nhất cho việc lưu trữ, vì tổng chi phí bảo trì máy chủ được phân bổ trên nhiều khách hàng.

VPS có chi phí vừa phải, phù hợp với Phù hợp với các doanh nghiệp vừa và nhỏ và đòi hỏi tính an toàn cao và sử dụng độc lập.

Chi phí cao hơn Shared hosting, VPS. Để quản lý máy chủ của mình, chi phí để thuê quản lý có thể bằng một nửa giá thuê.

Giảm chi phí lưu trữ do dùng bao nhiêu trả bấy nhiêu. Tuy nhiên giá thành chung vẫn còn cao so với các doanh nghiệp nhỏ.

VPS được quản lý và không được quản lý

Bạn có phân biệt được Managed hay unmanaged VPS? Đơn giản thôi, Managed là dạng VPS bên bán cho bạn sẽ quản lý cấu hình bảo mật tất cả cho bạn, bạn chỉ việc phát triển nội dung và nếu có bất cứ yêu cầu nào thì có thể yêu cầu bên bán VPS hỗ trợ cho bạn. Còn dạng unmanaged VPS là dạng VPS bạn tự mua VPS và tự động cài đặt Web panel, bạn không được hỗ trợ thao tác trực tiếp từ bên bán VPS, nếu có hỗ trợ thì họ sẽ hỗ trợ qua live chat hoặc ticket để hướng dẫn, họ sẽ không bao giờ thao tác trực tiếp trên tài khoản của bạn đó là điều bạn nên biết.

Tất nhiên, với dạng Managed VPS bạn phải trả mức giá khá cao so với unmanaged VPS, đương nhiên rồi, trả công cho họ setup, quản lý chứ 😀

WordPress trên VPS

Nếu bạn hiểu biết, bạn có thể chạy WordPress trên VPS của riêng mình nhưng đòi hỏi kiến ​​thức kỹ thuật đáng kể để quản trị và fix lỗi nếu VPS bạn gặp sự cố (Nói vậy thôi chứ nếu bạn làm quen 1 thời gian sẽ không khó như bạn tưởng).

Để đơn giản hóa cho việc cài đặt và quản lý website thì nếu bạn muốn tự cài đặt và quản lý VPS thì có thể cài các bảng điều khiển như CyberPanel (Khuyến khích nếu bạn muốn sử dụng công nghệ Openlitespeed hay Litespeed), AAPanel, VestaCP, HestiaCP, FastPanel (Khuyến khích nếu bạn muốn sử dụng công nghệ Nginx)

Nhà cung cấp unmanaged VPS chất lượng

Có hàng ngàn nhà cung cấp VPS trên toàn thế giới, tuy nhiên bạn nên sử dụng 1 trong các nhà cung cấp sau đây để có trải nghiệm tốt nhất.

Trong các nhà cung cấp trên mình khuyến khích bạn sử dụng Upcloud bởi độ ổn định và tài nguyên máy chủ phong phú, nếu bạn muốn tìm hiểu thêm thông tin về các nhà cung cấp VPS chất lượng có thể đọc 1 bài đánh giá chi tiết về các trên thế giới

Nếu bạn có bất cứ thắc mắc nào khác về VPS bạn có thể hỏi chúng tôi tại Group Vũ Trụ Số (Facebook) chúng tôi sẽ trả lời các câu hỏi trên đó.

Xin cảm ơn và hẹn gặp lại.

Hôm nay AlmaLinux OS Foundation đã công bố phát hành và cung cấp rộng rãi AlmaLinux OS 9.5 (codename Teal Serval), đây là phiên bản ổn định mới nhất của nhánh Red Hat Enterprise Linux (RHEL) miễn phí.

Được xây dựng từ cùng nguồn với Red Hat Enterprise Linux và hoàn toàn tương thích với Red Hat Enterprise Linux 9.5, AlmaLinux OS 9.5 ra mắt những cải tiến về giám sát hiệu suất hệ thống, trực quan hóa và thu thập dữ liệu hiệu suất hệ thống.

AlmaLinux OS 9.5 mang đến các luồng mô-đun được cập nhật hỗ trợ tốt hơn cho các ứng dụng web, các bản cập nhật bảo mật hướng đến việc tăng cường mật mã và các gói chính sách mật mã đã được cập nhật để mở rộng khả năng kiểm soát sang việc lựa chọn thuật toán trong Java.

Ngoài ra, chính sách SELinux đã được cập nhật để cung cấp một boolean cho phép QEMU Guest Agent thực thi các lệnh giới hạn, chương trình ca-certificates cũng được cập nhật để cung cấp các gốc CA đáng tin cậy trong định dạng thư mục OpenSSL.

Bản phát hành này còn cải thiện hiệu suất, độ tin cậy và khả năng mở rộng cho các nhà phát triển khi xây dựng và quản lý ứng dụng nhờ các phiên bản trình biên dịch mới, bao gồm GCC 14, LLVM 18.1.8, Rust 1.79.0, Go 1.22, GCC 11.5 và Annobin 12.70.

Các thành phần cập nhật khác trong bản phát hành AlmaLinux OS 9.5 bao gồm .NET 9.0, BIND 9.18, Apache 2.4.62, Node.js 22, GDB 14.2, Valgrind 3.23.0, SystemTap 5.1, elfutils 0.191, libabigail 2.5, PCP 6.2.2, Grafana 10.2.6, NSS 3.101 và OpenSSL 3.2.2.

Giống như bản phát hành Red Hat Enterprise Linux 9.5 thượng nguồn, AlmaLinux OS 9.5 được hỗ trợ bởi Linux kernel 5.14.0-427.13.1.el9_4. Bản phát hành này có thể tải xuống từ trang web chính thức dưới dạng ISO cài đặt cho kiến ​​trúc 64-bit (x86_64), AArch64 (ARM64), PowerPC 64-bit Little Endian (ppc64le) và IBM system Z (s390x).

Bản phát hành này nhắm đến người dùng mới và những người muốn thực hiện cài đặt mới. Người dùng AlmaLinux OS hiện tại có thể nâng cấp cài đặt của họ lên phiên bản mới bằng cách chạy lệnh bên dưới trong trình giả lập thiết bị đầu cuối hoặc bảng điều khiển ảo.

sudo dnf upgrade -y

Bạn có thể tải về AlmaLinux 9.5 theo các nguồn sau nếu cần.

ISO cài đặt hiện có sẵn trên các bản sao lưu cho tất cả 4 kiến ​​trúc:

Torrent cũng có sẵn tại:

AlmaLinux cũng cung cấp nhiều Cloud, Container và Live Images. Các bản dựng cho những thứ này sẽ được khởi chạy ngay khi kho lưu trữ công khai sẵn sàng.

Nguồn: AlmaLinux OS Foundation

Khi nếu bạn không để ý sẽ bị sai lệch thời gian dù bạn chọn đúng Múi giờ trong phần cài đặt website thì chúng cũng sẽ hiển thị không chính xác và trong bài viết này mình sẽ hướng dẫn cách để đồng bộ thời gian theo giờ địa phương cho các VPS sử dụng hệ điều hành AlmaLinux/CentOS/RHEL và Ubuntu/Debian

Đây là case mình gặp khi quản lý các VPS của khách + fix để thực hiện được chức năng chặn đăng nhập vào website vào buổi sáng, cụ thể chặn hacker login vào WordPress từ khoảng thời gian từ 0h sáng đến 6h sáng (Cần check chính xác thời gian nếu không sẽ bị khoá khi code check timezone localtime không đúng)

Đồng bộ thời gian VPS theo giờ địa phương

Trước tiên bạn có thể check timezone với lệnh timedatectl (áp dụng được cho các hệ điều hành AlmaLinux/CentOS/RHEL và Ubuntu/Debian)

[root@almalinux-vutruso~]# timedatectl
Local time: Thu 2024-08-01 03:44:18 +07
Universal time: Wed 2024-07-31 20:44:18 UTC
RTC time: Wed 2024-07-31 20:44:20
Time zone: Asia/Ho_Chi_Minh (+07, +0700)
System clock synchronized: no
NTP service: n/a
RTC in local TZ: no

Đầu ra cho thấy timezone đã đúng là Asia/Ho_Chi_Minh

Nếu VPS của bạn hiện sai location luôn có thể dùng lệnh sau để list các timezones khả dụng 

timedatectl list-timezones

Đặt múi giờ mong muốn với lệnh (thay Asia/Ho_Chi_Minh thành múi giờ bạn muốn)

sudo timedatectl set-timezone Asia/Ho_Chi_Minh

Sau đó xác nhận thay đổi

timedatectl

Để đồng bộ thời gian hệ thống thì bạn cần dùng tới Chrony và NTP (Network Time Protocol) đây là hai dịch vụ phổ biến để đồng bộ hóa thời gian hệ thống trên các VPS chạy các hệ điều hành như AlmaLinux và Ubuntu.

Đối với hệ thống Cũ (Nếu timedatectl không có sẵn)

Bạn có thể kiểm tra múi giờ hiện tại:

cat /etc/timezone

Thiết lập múi giờ

sudo ln -sf /usr/share/zoneinfo/Asia/Ho_Chi_Minh /etc/localtime

Khởi động lại dịch vụ thời gian của hệ thống

sudo service ntp restart

Trở lại với ví dụ đầu tiên mà tôi đã nêu ra, đầu ra của bạn timedatectl cho thấy múi giờ được đặt đúng thành Asia/Ho_Chi_Minh, nhưng đồng hồ hệ thống không được đồng bộ hóa và dịch vụ NTP không hoạt động. Nên phải bật đồng bộ hóa NTP để đảm bảo thời gian của máy chủ chính xác.

Cài đặt Chrony (NTP Client)

sudo dnf install chrony

Khởi động và kích hoạt dịch vụ Chrony

sudo systemctl start chronyd
sudo systemctl enable chronyd

Xác minh trạng thái dịch vụ Chrony

sudo systemctl status chronyd

Bật đồng bộ hóa thời gian

sudo timedatectl set-ntp true

Xác minh đồng bộ thời gian

timedatectl

Sau khi chạy các lệnh kia thì đầu ra sẽ đúng yêu cầu như sau:

[root@almalinux-vutruso~]# timedatectl
Local time: Wed 2024-07-31 20:45:25 +07
Universal time: Wed 2024-07-31 13:45:25 UTC
RTC time: Wed 2024-07-31 13:45:26
Time zone: Asia/Ho_Chi_Minh (+07, +0700)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

Local time: Wed 2024-07-31 20:45:25 +07 là chính xác với thời điểm mình viết bài viết này thay vì Local time: Thu 2024-08-01 03:44:18 +07 ở bước đầu mình check và các thông tin System clock synchronized: yes và NTP service: active đều active như bạn có thể thấy ở phần bôi đậm.

Bash script thay đổi timezone cho VPS

Nếu bạn có nhiều VPS và cần thao tác nhanh có thể sử dụng bash script được mình đóng gói này nhé, áp dụng cho 2 hệ điều hành Almalinux và Ubuntu

1. Tạo file: vts_set_timezone.sh sau đó dán code phía dưới vào.
2. Cho phép script này có quyền thực thi với lệnh chmod +x vts_set_timezone.sh
3. ./set_timezone.sh để chạy script
4. Tận hưởng

#!/bin/bash

# Set timezone
TIMEZONE="Asia/Ho_Chi_Minh"

# Function to set the timezone and configure NTP
vutruso_configure_timezone_and_ntp() {
    # Set the timezone using timedatectl
    sudo timedatectl set-timezone $TIMEZONE

    # Verify the timezone change
    echo "Timezone has been set to: $(timedatectl | grep 'Time zone')"

    # Install and configure chrony
    if [ -f /etc/redhat-release ]; then
        # AlmaLinux (RHEL-based)
        sudo dnf install -y chrony
        sudo systemctl start chronyd
        sudo systemctl enable chronyd
    elif [ -f /etc/lsb-release ]; then
        # Ubuntu
        sudo apt update
        sudo apt install -y chrony
        sudo systemctl start chrony
        sudo systemctl enable chrony
    else
        echo "Unsupported OS. This script supports AlmaLinux and Ubuntu."
        exit 1
    fi

    # Enable NTP
    sudo timedatectl set-ntp true

    # Verify the NTP change
    echo "NTP has been enabled: $(timedatectl | grep 'NTP synchronized')"
}

# Execute the configuration function
vutruso_configure_timezone_and_ntp

Hy vọng bài viết sẽ giúp ích được cho nhiều người.

Một tin cực kỳ vui đó là nhóm kỹ thuật phát hành Rocky Linux đã công bố xuất bản Rocky Linux 9.4 có chức năng tương tự phiên bản Red Hat Enterprise Linux 9.4 nhưng hoàn toàn miễn phí.

Red Hat Enterprise Linux (RHEL) là một trong những hệ điều hành dành cho doanh nghiệp phổ biến và mạnh mẽ. Nó được thiết kế cho môi trường sản xuất với yêu cầu cao về độ ổn định, bảo mật và khả năng mở rộng.

  • Bảo Mật: RHEL được biết đến với các tính năng bảo mật tiên tiến, bao gồm SELinux (Security-Enhanced Linux) giúp quản lý các chính sách an ninh nghiêm ngặt và tinh vi. Hệ thống cập nhật bảo mật thường xuyên và đáng tin cậy giúp bảo vệ server khỏi các lỗ hổng.
  • Ổn định và đáng tin Cậy: RHEL được phát triển với mục tiêu độ ổn định và đáng tin cậy cao. Bản phát hành chính của RHEL thường được hỗ trợ trong một khoảng thời gian dài, điều này rất thích hợp cho các ứng dụng doanh nghiệp cần thời gian vận hành lâu dài mà không gặp sự cố.
  • Hỗ trợ từ Red Hat: Khi mua bản quyền sử dụng RHEL, bạn cũng nhận được sự hỗ trợ trực tiếp từ Red Hat. Điều này bao gồm trợ giúp kỹ thuật, hỗ trợ về cài đặt và cấu hình, và giải đáp các thắc mắc. Sự hỗ trợ này có giá trị đặc biệt khi bạn gặp phải các vấn đề kỹ thuật phức tạp hoặc cần đảm bảo rằng hệ thống của bạn luôn được cập nhật và bảo mật.
  • Hệ sinh thái và tính tương thích: RHEL có một hệ sinh thái rộng lớn các ứng dụng và dịch vụ được hỗ trợ, cùng với sự tương thích rộng rãi trong ngành công nghiệp. Điều này làm cho việc tích hợp với các hệ thống và công nghệ khác trở nên dễ dàng hơn.
  • Cải tiến và đổi Mới: Red Hat liên tục đầu tư vào nghiên cứu và phát triển để đưa các công nghệ mới và cải tiến vào RHEL, giúp khách hàng tận dụng các công nghệ mới nhất và tốt nhất.

Tóm lại, nếu bạn cần một hệ điều hành có tính ổn định, bảo mật cao và được hỗ trợ kỹ thuật tốt cho một môi trường doanh nghiệp, RHEL là một lựa chọn xuất sắc. Tuy nhiên, nó cũng đi kèm với chi phí bản quyền, điều này cần được cân nhắc so với các tùy chọn miễn phí như Rocky Linux hay AlmaLinux, những lựa chọn này cũng cung cấp độ ổn định và bảo mật tương tự.

Dựa trên Red Hat Enterprise Linux 9.4 , Rocky Linux 9.4 giới thiệu các tính năng xây dựng image mới như khả năng chỉ định các điểm gắn tùy chỉnh tùy ý ngoại trừ các đường dẫn cụ thể dành riêng cho hệ điều hành, tạo các chế độ phân vùng khác nhau và tùy chỉnh các tùy chọn phù hợp cho cấu hình và thêm chúng vào các tùy chỉnh kế hoạch chi tiết bằng cách sử dụng các tùy chọn đã chọn và không được chọn để thêm và xóa các quy tắc.

Rocky Linux 9.4 cũng bổ sung trình tạo thiết bị thế hệ tiếp theo KIWI của openSUSE làm quy trình và quy trình xây dựng hình ảnh mới để xây dựng hình ảnh có tính năng hoàn chỉnh với hình ảnh cũ. Tuy nhiên, Image Factory vẫn đang được sử dụng để xây dựng hình ảnh Vagrant-VBox, Vagrant-VMware và OCP-Base (Oracle Cloud Platform).

Bản phát hành này cũng thay đổi tài khoản nhà xuất bản Rocky Linux cho Azure Marketplace và không dùng các hình ảnh trước đó nữa. Hình ảnh Azure của Rocky Linux hiện được xuất bản dưới tên resf.

Rocky Linux hiện đang có sẵn trên Azure nên việc cài đặt rất dễ dàng.

Về cơ bản, Rocky Linux 9.4 bao gồm các thành phần được cập nhật tương tự từ Red Hat Enterprise Linux 9.4 upstream như: SELinux 3.6, GnuTLS 3.8.3, nettle 3.9.1, p11-kit 0.25.3, libkcapi 1.4.0, stunnel 5.71, audit 3.1.2, Rsyslog 8.2310, SCAP Security Guide 0.1.72, openCryptoki 3.22.0, synce4l 1.0.0, chrony 4.5, linuxptp 4.2, elfutils 0.190, Go 1.21.0, Rust 1.75.0, LLVM 17.0.6, Git 2.43.0, Python 3.12, firewalld 1.3, nftables 1.0.9, iptables 1.8.10, PostgreSQL 16, MariaDB 10.11, nginx 1.24, PHP 8.2, Ruby 3.3.0, GCC 13, và Linux kernel 5.14.0-427.13.1.

Nếu bạn đang tìm giải pháp thay thế Red Hat Enterprise Linux miễn phí 100%, bạn có thể tải xuống Rocky Linux 9.4 cho 64-bit (x86_64), AArch64 (ARM64), PowerPC 64-bit Little Endian (ppc64le) và IBM System z ( s390x) ngay bây giờ từ trang web chính thức.

Bạn có thể xem qua nhật ký phát hành đường dẫn:

Trong thời gian tới hy vọng 1 số control Panel miễn phí sẽ hỗ trợ Rocky Linux 9.4 để được hưởng lợi từ hệ điều hành ổn định này.

Tham khảo: https://9to5linux.com/rocky-linux-9-4-released-as-another-free-red-hat-enterprise-linux-9-4-distro

Vừa qua liên cố gặp sự cố mạng nên tôi buộc phải check xem tình trạng nghẽn mạng từ đâu để giải thích cho khách hàng biết về sự cố khi khách lướt web rất chậm và nhiều trường hợp nếu ping thì sẽ bị timeout luôn.

Tôi sử dụng công cụ MTR để chuẩn đoán xem kết nối bị nghẽn hay gặp sự cố ở VPS hay do nghẽn tại ISP nào đó… Khi chạy MTR nó sẽ khám phá kết nối mạng giữa hệ thống cục bộ và máy chủ từ xa mà bạn chỉ định.

Giống như traceroute, MTR in thông tin về đường dẫn được thực hiện bởi các gói. Từ máy chủ lưu trữ MTR đang chạy đến máy chủ đích do người dùng chỉ định. Cũng có thể xác định đường dẫn đến một máy từ xa trong khi in phần trăm phản hồi, cũng như thời gian phản hồi của tất cả các bước nhảy mạng giữa hệ thống cục bộ và máy từ xa.

Trong quá trình check, MTR tạo ra một số thống kê hữu ích trên mỗi máy. Chúng được cập nhật theo thời gian thực. Khi thực thi chương trình, các gói ICMP được gửi đi điều chỉnh thời gian tồn tại (TTL), để xem chuỗi các bước nhảy mà gói thực hiện giữa điểm gốc và điểm đến. Thời gian phản hồi hoặc mất gói tin tăng đột ngột có thể là dấu hiệu của kết nối kém, máy chủ quá tải hoặc thậm chí là tấn công man-in-the-middle.

Dưới đây là mẹo để xác định nhanh sự cố là chính, còn công cụ MTR còn rất nhiều tính năng khác mà tôi sẽ giới thiệu ở 1 bài viết sau này.

Nếu bạn sử dụng VPS hãy login vào VPS và cài mtr theo lệnh phía dưới, copy tương ứng với hệ điều hành của mình nhé.

Hệ điều hành RHEL Centos/Almalinux

yum install mtr

Hệ điều hành Ubuntu & Debian

apt install mtr

Hệ điều hành Windows

https://github.com/White-Tiger/WinMTR

Hệ điều hành macOS

https://macappstore.org/mtr/

Sau khi cài xong mtr bạn có thể dùng lệnh mtr -v để xem phiên bản mtr

[root@sg2 ~]# mtr -v
mtr 0.92

Tiếp theo bạn có thể chạy lệnh sau để xem mạng bị nghẽn nơi đâu.

mtr -n -r -c 1 171.247.105.251

171.247.105.251 là địa chỉ IP của bạn, lệnh này tôi dán ở SSH để xác định đường đi từ máy chủ tới IP của người truy cập web, với mtr nó sẽ liệt kê được vị trí mạng bị nghẽn.

Để biết được IP của chính mình bạn có thể truy cập vào https://nordvpn.com/what-is-my-ip/ hoặc https://www.showmyip.com/

Tùy chọn -n ngăn độ phân giải DNS hiển thị trực tiếp địa chỉ IP, -r tạo báo cáo và -c 1 chỉ định rằng bạn chỉ muốn gửi một gói, như vậy sẽ cung cấp cho bạn phân tích tuyến mạng đến địa chỉ IP được chỉ định.

Như ảnh bạn có thể thấy có đến 2 vị trí bị mất gói loss 100%

Bạn có thể check location 2 IP là: 98.98.230.187 (Zenlayer bên Singapore) và 27.68.250.19 (Viettel HCMC) suy ra khi chuyển tiếp hoặc gói đi từ Zenlayer đến Viettel có vấn đề.

Khi tôi dùng phần mềm MTR trên Windows để xác định hướng ngược lại thì mạng cũng rất bất ổn do sự cố đứt 3 sợi cáp cùng 1 lúc tại thời điểm này, nên cho kết nối giữa Việt Nam và Singapore cực kỳ tệ.

MTR (My Traceroute) là công cụ chẩn đoán bắt buộc phải có đối với người dùng Linux, nó cung cấp khả năng phân tích mạng theo thời gian thực có thể xác định và giải quyết các sự cố mạng một cách hiệu quả.

Các phép đo độ trễ và mất gói chính xác của nó cho phép phân tích chuyên sâu về hiệu suất mạng, khiến nó trở thành tài sản vô giá cho quản trị viên hệ thống, kỹ sư mạng và bất kỳ ai muốn tối ưu hóa mạng của họ.

MTR tự hào có giao diện dễ sử dụng với chức năng mạnh mẽ, cho phép người dùng thực hiện khắc phục sự cố mạng nhanh chóng và hiệu quả. Độ tin cậy và hiệu quả của nó làm cho nó trở thành một công cụ thiết yếu để tối ưu hóa hiệu suất mạng.

Tóm lại, sức mạnh và độ chính xác của MTR đảm bảo rằng người dùng Linux có thể dễ dàng chẩn đoán và khắc phục sự cố mạng, khiến nó trở thành công cụ không thể thiếu trong kho vũ khí của bất kỳ kỹ sư mạng nào.