Posted inCentos

Cấu hình iSCSI Initiator trên CentOS Stream 9: Kết nối ổ đĩa SAN/NAS cho môi trường doanh nghiệp

CentOS tutorial - IT technology blog
CentOS tutorial - IT technology blog

iSCSI hay Fibre Channel — Chọn gì cho hạ tầng của bạn?

Mình từng làm việc ở một công ty có hệ thống storage NetApp, và câu hỏi đầu tiên khi cần kết nối server Linux vào SAN luôn là: iSCSI hay Fibre Channel (FC)? Hai cái này không phải “cái nào tốt hơn” mà là “cái nào phù hợp với hạ tầng hiện có”.

FC latency xuống dưới 1ms và throughput cực ổn định — nhưng cần HBA card riêng (~$300–500/card), switch FC riêng, chi phí ban đầu dễ lên đến vài chục nghìn đô. iSCSI chạy trên Ethernet/IP sẵn có, không cần phần cứng đặc biệt. Với 10GbE thì throughput đủ cho hầu hết workload doanh nghiệp vừa. Với môi trường SMB hoặc dev/test, lựa chọn thực tế hơn khá rõ ràng.

iscsiadm vs Cockpit vs iSNS: Nên dùng gì?

Trên CentOS/RHEL, có vài cách để quản lý iSCSI initiator — mình đã thử cả ba và đây là đánh giá thực tế:

  • iscsiadm (CLI): Tool chính thức, đầy đủ tính năng, scriptable — đây là cái dùng được ở production. Cú pháp hơi verbose nhưng quen rồi thì không vấn đề gì.
  • Cockpit + iSCSI module: GUI qua browser, tiện cho admin không quen CLI — nhưng ít control, khó debug khi có lỗi.
  • iSNS (Internet Storage Name Service): Như DNS cho iSCSI, tự động discover trong môi trường storage lớn — cần cài iSNS server riêng, overkill nếu bạn chỉ có vài chục LUN.

sendtargets vs Static Node vs iSNS

Phần này ít bài nói đến nhưng lại quan trọng khi setup:

  • sendtargets: Query thẳng iSCSI portal, server tự trả về danh sách target — đơn giản, phù hợp khi biết địa chỉ portal. Đây là cách mình dùng 90% thời gian.
  • Static node: Cấu hình trực tiếp IQN của target mà không cần discovery — dùng khi biết chính xác target và muốn kiểm soát chặt hơn.
  • iSNS: Auto-discover trong môi trường enterprise lớn — cần server iSNS riêng, phù hợp khi có hàng trăm target.

Trong thực tế, 90% trường hợp bạn chỉ cần sendtargets + iscsiadm — không phụ thuộc server phụ, script được dễ dàng, và debug cũng đơn giản hơn nhiều.

Triển khai thực tế: Từ cài đặt đến mount ổ đĩa

Bước 1: Cài đặt iSCSI Initiator

CentOS Stream 9 dùng package iscsi-initiator-utils:

sudo dnf install -y iscsi-initiator-utils
sudo systemctl enable --now iscsid

Kiểm tra IQN (iSCSI Qualified Name) của initiator — đây là “địa chỉ định danh” server của bạn trên hệ thống storage:

cat /etc/iscsi/initiatorname.iscsi
# Output: InitiatorName=iqn.1994-05.com.redhat:xxxxxxxx

IQN này là unique per machine. Nếu clone VM mà không đổi IQN, sẽ xảy ra conflict với session đang active — đây là lỗi mình từng gặp khi migrate server.

Bước 2: Cấu hình CHAP Authentication

Bước này thường bị skip với lý do “storage network nội bộ mà cần auth gì”. Nhưng iSCSI không có encryption mặc định — traffic đi plaintext. CHAP ít nhất giúp xác thực, không để target mở với toàn bộ network segment:

sudo vi /etc/iscsi/iscsid.conf

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

# Enable CHAP
node.session.auth.authmethod = CHAP

# Thông tin xác thực (hỏi admin storage để lấy)
node.session.auth.username = your_username
node.session.auth.password = your_password

# Nếu cần mutual CHAP (target xác thực ngược lại initiator)
node.session.auth.username_in = target_username
node.session.auth.password_in = target_password

Bước 3: Discovery — Tìm iSCSI Target

Dùng sendtargets để discover (thay 192.168.1.100 bằng IP của iSCSI portal):

sudo iscsiadm -m discovery -t sendtargets -p 192.168.1.100:3260

Output sẽ liệt kê các target available:

192.168.1.100:3260,1 iqn.2024-01.com.company:storage.lun01
192.168.1.100:3260,1 iqn.2024-01.com.company:storage.lun02

Bước 4: Login vào Target

Login vào tất cả target đã discover:

sudo iscsiadm -m node --loginall=automatic

Hoặc login vào target cụ thể:

sudo iscsiadm -m node \
  --targetname "iqn.2024-01.com.company:storage.lun01" \
  --portal "192.168.1.100:3260" \
  --login

Kiểm tra session đang active:

sudo iscsiadm -m session -P 1

Bước 5: Xác nhận ổ đĩa xuất hiện

Login thành công thì kernel nhận LUN như SCSI device thông thường — không cần reboot:

lsblk
# hoặc
sudo fdisk -l | grep "Disk /dev/sd"

Nếu thấy /dev/sdb, /dev/sdc… xuất hiện thêm — đó là iSCSI LUN của bạn.

Bước 6: Format và Mount

# Format với XFS (khuyến nghị cho storage workload)
sudo mkfs.xfs /dev/sdb

# Tạo mount point
sudo mkdir -p /mnt/iscsi-data

# Mount thử
sudo mount /dev/sdb /mnt/iscsi-data

# Kiểm tra
df -hT /mnt/iscsi-data

Bước 7: Auto-mount khi khởi động — Đừng bỏ sót bước này

iSCSI mount khác với ổ đĩa thông thường ở một điểm then chốt: network phải sẵn sàng trước khi mount. Thiếu option _netdev trong /etc/fstab, server có thể bị stuck ở boot screen chờ mount timeout — mình từng thấy server mất thêm 90 giây mỗi lần boot chỉ vì lỗi này:

sudo blkid /dev/sdb  # Lấy UUID
sudo vi /etc/fstab
# Thêm dòng (thay UUID thực tế):
UUID=xxxx-xxxx-xxxx  /mnt/iscsi-data  xfs  defaults,_netdev,nofail  0 0

Option nofail tránh server bị stuck boot nếu storage target không available. Enable các service liên quan:

sudo systemctl enable iscsi iscsid
sudo systemctl enable remote-fs.target

Mẹo thực chiến — Học từ đợt migrate khẩn cấp

Khi CentOS 8 EOL, mình phải migrate gấp 5 server sang Rocky Linux trong 1 tuần — và iSCSI là phần stress nhất vì downtime storage ảnh hưởng trực tiếp đến production database. Đây là những gì mình học được từ đợt đó:

  • Document IQN trước khi migrate: IQN trên máy cũ khác với máy mới. Nếu storage admin cấu hình ACL theo IQN, bạn phải báo họ cập nhật — không thì login xong mà không thấy LUN, mất cả buổi debug.
  • Dùng multipath nếu có thể: Package device-mapper-multipath cho phép nhiều path đến cùng 1 LUN — fail-over tự động nếu 1 đường mạng đứt. Với production database, đây không phải “nice to have” mà gần như bắt buộc.
  • Kiểm tra MTU đồng nhất: Jumbo Frames (MTU 9000) cải thiện throughput iSCSI đáng kể, nhưng phải đồng nhất toàn bộ path từ NIC → switch → storage array. Mismatch MTU gây packet fragmentation, throughput giảm 30–40% mà nhìn log không thấy gì bất thường — loại lỗi mất vài tiếng mới tìm ra.
  • Network riêng cho storage traffic: Đừng dùng chung NIC với management traffic. Ít nhất dùng VLAN riêng — tránh tình huống backup job đang chạy làm nghẽn storage của database.

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

Login failed — lỗi authentication

# Cập nhật CHAP trực tiếp cho node
sudo iscsiadm -m node \
  --targetname "iqn.2024-01.com.company:storage.lun01" \
  --portal "192.168.1.100:3260" \
  -o update \
  -n node.session.auth.authmethod -v CHAP

sudo iscsiadm -m node \
  --targetname "iqn.2024-01.com.company:storage.lun01" \
  --portal "192.168.1.100:3260" \
  -o update \
  -n node.session.auth.username -v your_user \
  -n node.session.auth.password -v your_pass

Target không kết nối lại sau reboot

# Đặt node startup mode về automatic
sudo iscsiadm -m node -o update -n node.startup -v automatic

# Verify service đang chạy
sudo systemctl status iscsid iscsi

Logout an toàn khi maintenance

# Unmount trước — QUAN TRỌNG, không skip bước này
sudo umount /mnt/iscsi-data
sudo sync

# Rồi mới logout
sudo iscsiadm -m node --logoutall=all

iSCSI trên CentOS Stream 9 production-ready và đủ ổn định cho database storage — mình đang chạy thực tế ở môi trường vài chục LUN mà không có vấn đề gì. Setup thường thất bại không phải vì tool phức tạp, mà vì ba điểm hay bị bỏ qua: CHAP authentication, multipath cho HA, và _netdev trong fstab. Làm đúng ba cái này thì còn lại khá suôn sẻ.

Share:
Tags: