NVMe-over-TCP trong Sản xuất: Kiến trúc Kernel Linux, SPDK & Lưu trữ Kubernetes Hiệu suất cao

NVMe-over-TCP (NVMe/TCP) cung cấp một giải pháp truyền tải lưu trữ khối mạnh mẽ, hiệu suất cao qua Ethernet tiêu chuẩn, tận dụng hiệu quả bộ lệnh NVMe. Hướng dẫn này trình bày chi tiết kiến trúc, các cân nhắc triển khai và tích hợp NVMe/TCP vào Kubernetes để có được lưu trữ IOPS cao, độ trễ thấp. Chúng ta sẽ phân tích các tác động về hiệu suất của việc triển khai trong không gian kernel so với không gian người dùng (SPDK) và chứng minh cách đạt được các mục tiêu hiệu suất khắt khe.

Tổng quan kiến trúc NVMe/TCP

NVMe/TCP đóng gói các lệnh và dữ liệu NVMe trong các gói TCP/IP. Điều này cho phép cơ sở hạ tầng mạng tiêu chuẩn truyền tải lưu lượng lưu trữ hiệu suất cao, loại bỏ nhu cầu về phần cứng Fibre Channel hoặc InfiniBand chuyên dụng.

Các thành phần chính

1. NVMe Host: Trình khởi tạo, thường là máy chủ Linux hoặc node Kubernetes, sử dụng lưu trữ NVMe/TCP.
2. NVMe Target: Máy chủ lưu trữ xuất các không gian tên NVMe qua TCP. Đây có thể là một thiết bị lưu trữ chuyên dụng, một máy chủ đa năng chạy LVM/ZFS với các ổ NVMe, hoặc một giải pháp dựa trên SPDK.
3. Giao thức NVMe-oF (NVMe over Fabrics): Đặc tả tổng thể định nghĩa cách các lệnh NVMe được truyền tải qua các loại mạng khác nhau, bao gồm TCP, RDMA (RoCE, iWARP) và Fibre Channel.

Ngăn xếp NVMe/TCP của Linux Kernel

Linux kernel cung cấp hỗ trợ trình khởi tạo và đích NVMe/TCP gốc.

• Trình khởi tạo: Mô-đun kernel nvme-tcp xử lý việc thiết lập kết nối, gửi lệnh và truyền dữ liệu. Nó tích hợp với lớp khối, trình bày các không gian tên NVMe từ xa dưới dạng các thiết bị khối cục bộ (ví dụ: /dev/nvme0n1).
• Đích: Mô-đun kernel nvmet-tcp hiển thị các thiết bị NVMe cục bộ hoặc thiết bị khối dưới dạng các không gian tên NVMe/TCP.

Cách tiếp cận kernel-native này mang lại sự đơn giản và khả năng tương thích rộng rãi nhưng lại gây ra chi phí chuyển đổi ngữ cảnh giữa không gian người dùng và kernel, cũng như xử lý ngăn xếp TCP/IP.

SPDK (Storage Performance Development Kit)

SPDK là một tập hợp các thư viện và công cụ trong không gian người dùng để viết các ứng dụng lưu trữ hiệu suất cao, có khả năng mở rộng. Đối với NVMe/TCP, SPDK cung cấp:

• Trình điều khiển NVMe trong không gian người dùng: Bỏ qua lớp khối và trình điều khiển NVMe của kernel, truy cập trực tiếp các thiết bị NVMe thông qua UIO (Userspace I/O) hoặc VFIO (Virtual Function I/O).
• Ngăn xếp TCP/IP trong không gian người dùng: SPDK bao gồm ngăn xếp TCP/IP chế độ thăm dò (polled-mode) được tối ưu hóa cao của riêng nó, loại bỏ các chuyển đổi ngữ cảnh kernel và xử lý dựa trên ngắt. Điều này rất quan trọng để đạt được độ trễ cực thấp và IOPS cao.
• Chế độ thăm dò: Thay vì dựa vào các ngắt, SPDK liên tục thăm dò để hoàn thành I/O và các sự kiện mạng, giảm độ trễ dao động.

Cách tiếp cận SPDK mang lại hiệu suất vượt trội nhưng yêu cầu các lõi CPU và bộ nhớ chuyên dụng, đồng thời có thể phức tạp hơn trong việc cấu hình.

So sánh kiến trúc: NVMe/TCP so với các giải pháp thay thế

Triển khai NVMe/TCP trong Kubernetes

Chúng ta sẽ tập trung vào một đích NVMe/TCP dựa trên kernel để đơn giản và áp dụng rộng rãi, chứng minh cách đạt được hiệu suất cao. Đối với SPDK, các nguyên tắc tương tự, nhưng việc thiết lập đích phức tạp hơn.

Điều kiện tiên quyết

• Cụm Kubernetes (v1.20+)
• Linux kernel 5.0+ trên tất cả các node (để hỗ trợ NVMe/TCP mạnh mẽ)
• nvme-cli được cài đặt trên các node đích và trình khởi tạo
• multipath-tools được cài đặt trên các node trình khởi tạo

1. Thiết lập đích NVMe/TCP (Ví dụ: Máy chủ lưu trữ chuyên dụng)

Giả sử một máy chủ lưu trữ với một NVMe SSD (/dev/nvme0n1). Chúng ta sẽ tạo một logical volume LVM và hiển thị nó.

# On the NVMe/TCP Target Server

# 1. Ensure nvmet-tcp module is loaded
sudo modprobe nvmet-tcp

# 2. Create a Volume Group and Logical Volume (example: 100GB)
#    Replace /dev/nvme0n1 with your actual NVMe device
sudo pvcreate /dev/nvme0n1
sudo vgcreate nvme_vg /dev/nvme0n1
sudo lvcreate -L 100G -n nvme_lv nvme_vg

# 3. Configure NVMe/TCP Target
#    Create a subsystem (nqn.2023-10.com.locionic:k8s-storage)
#    This NQN (NVMe Qualified Name) uniquely identifies the storage subsystem.
sudo nvme target create -t tcp -n nqn.2023-10.com.locionic:k8s-storage

# 4. Add a controller (listener) for the target
#    Replace 192.168.1.100 with your target server's IP address
sudo nvme target add-listener -t tcp -n nqn.2023-10.com.locionic:k8s-storage -a 192.168.1.100 -s 4420

# 5. Create a namespace and attach the logical volume
#    The namespace ID (nsid) must be unique within the subsystem.
sudo nvme target add-namespace -t tcp -n nqn.2023-10.com.locionic:k8s-storage -d /dev/nvme_vg/nvme_lv -s 1

# 6. Enable the subsystem
sudo nvme target enable -t tcp -n nqn.2023-10.com.locionic:k8s-storage

# Verify target configuration
sudo nvme target show

2. Thiết lập trình khởi tạo Kubernetes (Worker Nodes)

Mỗi node worker Kubernetes sẽ sử dụng lưu trữ NVMe/TCP cần mô-đun trình khởi tạo và multipath-tools.

# On each Kubernetes Worker Node

# 1. Ensure nvme-tcp module is loaded
sudo modprobe nvme-tcp

# 2. Install multipath-tools
sudo apt update && sudo apt install -y multipath-tools # Debian/Ubuntu
# OR
sudo yum install -y device-mapper-multipath # CentOS/RHEL

# 3. Configure multipath (optional but highly recommended for HA)
#    Edit /etc/multipath.conf
sudo tee /etc/multipath.conf <<EOF
defaults {
    user_friendly_names yes
    find_multipaths yes
    # Increase queue depth for better performance with NVMe
    queue_without_daemon no
    max_sectors_kb 512
}
blacklist {
    devnode "^(ram|loop|fd|md|dm-|sr|scd|st)[0-9]*"
    devnode "^hd[a-z]"
    devnode "^sd[a-z]"
}
EOF

# 4. Restart multipathd
sudo systemctl enable multipathd
sudo systemctl restart multipathd

# 5. Connect to the NVMe/TCP target (manual test)
#    Replace 192.168.1.100 with your target server's IP
#    Replace nqn.2023-10.com.locionic:k8s-storage with your target NQN
sudo nvme connect -t tcp -n nqn.2023-10.com.locionic:k8s-storage -a 192.168.1.100 -s 4420

# 6. Verify connection and device
#    You should see a new /dev/nvmeXnY device
lsblk
sudo nvme list

3. Triển khai trình điều khiển CSI của Kubernetes

Để cấp phát động và tích hợp liền mạch, một trình điều khiển Container Storage Interface (CSI) là rất cần thiết. Mặc dù có thể tồn tại một trình điều khiển CSI NVMe/TCP chung, nhưng thường bạn sẽ sử dụng một trình điều khiển dành riêng cho nhà cung cấp hoặc điều chỉnh một trình điều khiển CSI lưu trữ khối chung để quản lý các kết nối NVMe/TCP. Ở đây, chúng ta sẽ phác thảo một trình điều khiển CSI khái niệm tận dụng nvme-cli để quản lý kết nối.

Một trình điều khiển CSI cấp độ sản xuất sẽ xử lý:

• Cấp phát động các không gian tên NVMe trên đích.
• Kết nối/ngắt kết nối các thiết bị NVMe/TCP trên các node worker.
• Cấu hình đa đường.
• Xuất bản và hủy xuất bản volume.

Ví dụ: Trình điều khiển CSI khái niệm cho NVMe/TCP

Đây là một biểu diễn đơn giản hóa. Một trình điều khiển CSI thực tế sẽ phức tạp hơn, liên quan đến các dịch vụ gRPC, bộ điều khiển và các plugin node.

# csi-nvmetcp-driver.yaml
apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
  name: nvmetcp.locionic.com
spec:
  attachRequired: false # NVMe/TCP devices are directly attached
  podInfoOnMount: false
  volumeLifecycleModes:
    - Persistent
    - Ephemeral
  fsGroupPolicy: File

# storageclass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nvmetcp-fast
provisioner: nvmetcp.locionic.com # Must match the CSIDriver name
parameters:
  targetIp: "192.168.1.100" # IP of your NVMe/TCP target
  targetNqn: "nqn.2023-10.com.locionic:k8s-storage"
  targetPort: "4420"
  # Other parameters for dynamic provisioning (e.g., size, LVM details)
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true

# pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-nvmetcp-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: nvmetcp-fast
  resources:
    requests:
      storage: 10Gi

# pod-with-pvc.yaml
apiVersion: v1
kind: Pod
metadata:
  name: fio-test-pod
spec:
  containers:
    - name: fio
      image: ghcr.io/locionic/fio:latest # A custom FIO image with nvme-cli
      command: ["/bin/bash", "-c", "sleep infinity"]
      volumeMounts:
        - name: nvmetcp-volume
          mountPath: /data
  volumes:
    - name: nvmetcp-volume
      persistentVolumeClaim:
        claimName: my-nvmetcp-pvc

4. Cấu hình I/O đa đường

Để có tính khả dụng cao và tăng băng thông, hãy cấu hình nhiều đường dẫn đến đích NVMe/TCP. Điều này yêu cầu đích phải hiển thị cùng một không gian tên thông qua nhiều địa chỉ IP hoặc giao diện mạng.

Phía đích (Ví dụ với hai IP):

# On NVMe/TCP Target Server
# Assuming 192.168.1.100 and 192.168.1.101 are target IPs
sudo nvme target add-listener -t tcp -n nqn.2023-10.com.locionic:k8s-storage -a 192.168.1.100 -s 4420
sudo nvme target add-listener -t tcp -n nqn.2023-10.com.locionic:k8s-storage -a 192.168.1.101 -s 4420

Phía trình khởi tạo (Kubernetes Worker Node):

Lệnh nvme connect sẽ tự động phát hiện nhiều đường dẫn nếu NQN đích và cổng giống nhau nhưng IP khác nhau. multipathd sau đó sẽ quản lý các đường dẫn này.

# On Kubernetes Worker Node
# Connect to both target IPs
sudo nvme connect -t tcp -n nqn.2023-10.com.locionic:k8s-storage -a 192.168.1.100 -s 4420
sudo nvme connect -t tcp -n nqn.2023-10.com.locionic:k8s-storage -a 192.168.1.101 -s 4420

# Verify multipath device
sudo multipath -ll
# Expected output will show a single device with multiple paths
# e.g., mpatha (360014050000000000000000000000000) dm-0 NVME,Linux
# size=100G features='0' hwhandler='0' wp=rw
# |- 0:0:0:0 nvme0n1 8:0 active ready running
# `- 1:0:0:0 nvme1n1 8:16 active ready running

Trình điều khiển CSI sẽ trừu tượng hóa điều này, kết nối với tất cả các IP đích được chỉ định.

Đánh giá hiệu suất (500k+ Random Write IOPS)

Để đạt được 500k+ random write IOPS với độ trễ dưới 100µs, một số yếu tố rất quan trọng:

1. NVMe SSD nhanh: Lưu trữ cơ bản trên đích phải có khả năng.
2. Mạng băng thông cao: Khuyến nghị 25GbE hoặc 100GbE.
3. Tài nguyên CPU: Các lõi chuyên dụng cho SPDK hoặc đủ lõi cho I/O dựa trên kernel.
4. Các tham số FIO tối ưu:
   • iodepth: Độ sâu hàng đợi cao để bão hòa thiết bị.
   • numjobs: Nhiều công việc song song.
   • direct=1: Bỏ qua bộ đệm OS.
   • ioengine=libaio hoặc ioengine=io_uring (đối với các kernel hiện đại).
   • randwrite: Ghi ngẫu nhiên.
   • bs=4k: Kích thước khối tiêu chuẩn.

Ví dụ kiểm tra FIO (bên trong fio-test-pod):

# On the fio-test-pod
# Ensure /data is mounted from the NVMe/TCP PVC
cd /data

# Create a test file
dd if=/dev/zero of=testfile bs=1M count=1024 status=progress

# FIO command for 4K random writes
fio --name=randwrite_test \
    --ioengine=libaio \
    --iodepth=128 \
    --rw=randwrite \
    --bs=4k \
    --direct=1 \
    --numjobs=4 \
    --size=10G \
    --runtime=60 \
    --filename=testfile \
    --group_reporting \
    --output-format=json

Đầu ra dự kiến (trích đoạn cho 500k+ IOPS, độ trễ dưới 100µs):

{
  "jobs": [
    {
      "jobname": "randwrite_test",
      "write": {
        "io_bytes": 10737418240,
        "bw": 178957,
        "iops": 44739,
        "lat_ns": {
          "min": 20000,
          "max": 150000,
          "mean": 75000,
          "stddev": 15000
        }
      }
    },
    {
      "jobname": "randwrite_test",
      "write": {
        "io_bytes": 10737418240,
        "bw": 178957,
        "iops": 44739,
        "lat_ns": {
          "min": 20000,
          "max": 150000,
          "mean": 75000,
          "stddev": 15000
        }
      }
    },
    {
      "jobname": "randwrite_test",
      "write": {
        "io_bytes": 10737418240,
        "bw": 178957,
        "iops": 44739,
        "lat_ns": {
          "min": 20000,
          "max": 150000,
          "mean": 75000,
          "stddev": 15000
        }
      }
    },
    {
      "jobname": "randwrite_test",
      "write": {
        "io_bytes": 10737418240,
        "bw": 178957,
        "iops": 44739,
        "lat_ns": {
          "min": 20000,
          "max": 150000,
          "mean": 75000,
          "stddev": 15000
        }
      }
    }
  ],
  "global_data": {
    "write": {
      "io_bytes": 42949672960,
      "bw": 715828,
      "iops": 178957,
      "lat_ns": {
        "min": 20000,
        "max": 150000,
        "mean": 75000,
        "stddev": 15000
      }
    }
  }
}

Lưu ý: Đầu ra FIO ví dụ trên cho thấy ~179k IOPS cho 4 công việc. Để đạt 500k+, bạn cần mở rộng numjobs, iodepth, và có thể chạy nhiều phiên bản FIO trên các pod/node khác nhau, đảm bảo đích và mạng cơ bản có thể duy trì tải.

Những vấn đề và khắc phục sự cố trong sản xuất

1. Mô-đun Kernel chưa được tải:

   • Triệu chứng: nvme connect thất bại với "No such device" hoặc lsmod | grep nvme-tcp không hiển thị gì.
   • Khắc phục: sudo modprobe nvme-tcp và sudo modprobe nvmet-tcp (trên đích). Đảm bảo chúng tồn tại sau khi khởi động lại bằng cách thêm chúng vào /etc/modules-load.d/nvme.conf.

2. Sự cố kết nối mạng:

   • Triệu chứng: nvme connect hết thời gian chờ hoặc không thể thiết lập kết nối.
   • Khắc phục: Xác minh địa chỉ IP, mặt nạ mạng con và cổng. Kiểm tra tường lửa (firewalld, ufw, iptables) trên cả đích và trình khởi tạo. Đảm bảo cổng 4420 được mở. Sử dụng ping, traceroute, netcat để chẩn đoán.

3. NQN không khớp:

   • Triệu chứng: nvme connect thất bại với "Invalid NQN" hoặc tương tự.
   • Khắc phục: Kiểm tra kỹ NQN được sử dụng trong nvme connect khớp chính xác với những gì đã được cấu hình trên đích (nvme target create -n ...). NQN phân biệt chữ hoa chữ thường.

4. Lỗi cấu hình đa đường:

   • Triệu chứng: Chỉ có một đường dẫn hoạt động, hoặc multipath -ll hiển thị các thiết bị riêng biệt thay vì một thiết bị đa đường duy nhất.
   • Khắc phục: Đảm bảo multipathd đang chạy. Xác minh /etc/multipath.conf được cấu hình chính xác, đặc biệt là user_friendly_names và find_multipaths. Đảm bảo tất cả các IP đích được kết nối với cùng một NQN. Khởi động lại multipathd sau khi thay đổi.

5. Nút thắt cổ chai hiệu suất:

   • Triệu chứng: Không đạt được mục tiêu IOPS hoặc độ trễ.
   • Khắc phục:
     • Đích: Kiểm tra mức sử dụng CPU (top, htop), I/O đĩa (iostat -x 1), I/O mạng (sar -n DEV 1). NVMe SSD cơ bản có bị bão hòa không?
     • Mạng: Kiểm tra mức sử dụng liên kết mạng (iftop, nload). Có mất gói tin không? Cổng chuyển mạch có được cấu hình đúng không (ví dụ: kiểm soát luồng, khung jumbo)?
     • Trình khởi tạo: Kiểm tra mức sử dụng CPU. Đảm bảo iodepth và numjobs trong FIO đủ cao. Cân nhắc io_uring cho các kernel mới hơn. Đối với SPDK, đảm bảo cách ly lõi CPU và các trang lớn được cấu hình.
     • Điều chỉnh ngăn xếp TCP của Kernel: Đối với NVMe/TCP của kernel, hãy cân nhắc điều chỉnh net.core.somaxconn, net.ipv4.tcp_tw_reuse, net.ipv4.tcp_max_syn_backlog, net.ipv4.tcp_fin_timeout.

6. Sự cố trình điều khiển CSI:

   • Triệu chứng: PVC vẫn đang chờ xử lý, các pod không thể gắn volume.
   • Khắc phục: Kiểm tra nhật ký bộ điều khiển và plugin node của trình điều khiển CSI (kubectl logs -n <csi-namespace> <pod-name>). Xác minh định nghĩa CSIDriver và StorageClass. Đảm bảo các quyền cần thiết cho trình điều khiển CSI để thực thi các lệnh nvme-cli trên các node worker (ví dụ: thông qua các container đặc quyền hoặc gắn hostPath cho các tệp nhị phân).

Các câu hỏi thường gặp

1. Lợi thế chính của NVMe/TCP so với iSCSI là gì? NVMe/TCP tận dụng bộ lệnh NVMe song song, hiệu quả cao, được thiết kế cho các SSD hiện đại, trực tiếp qua TCP/IP. iSCSI sử dụng bộ lệnh SCSI cũ hơn, gây ra nhiều chi phí hơn và ít được tối ưu hóa cho tính song song của các thiết bị NVMe. Điều này dẫn đến IOPS cao hơn đáng kể và độ trễ thấp hơn cho NVMe/TCP.

2. Khi nào tôi nên cân nhắc SPDK thay vì NVMe/TCP của kernel? SPDK lý tưởng cho các yêu cầu hiệu suất cực cao, nơi mỗi micro giây độ trễ và mỗi IOPS đều quan trọng. Nó bỏ qua ngăn xếp TCP/IP và lớp khối của kernel, loại bỏ các chuyển đổi ngữ cảnh và chi phí ngắt bằng cách sử dụng thăm dò trong không gian người dùng. Điều này phải trả giá bằng sự phức tạp gia tăng, phân bổ lõi CPU chuyên dụng và có thể tiêu thụ bộ nhớ cao hơn. Đối với hầu hết các ứng dụng hiệu suất cao, NVMe/TCP của kernel với việc điều chỉnh phù hợp là đủ.

3. NVMe/TCP có phù hợp với môi trường Kubernetes đa người thuê không? Có, với việc quản lý tài nguyên cẩn thận. Mỗi kết nối NVMe/TCP tiêu thụ tài nguyên trên node worker. Một trình điều khiển CSI được thiết kế tốt có thể quản lý các kết nối này. Đối với đa người thuê, hãy cân nhắc sử dụng các hệ thống con NVMe hoặc không gian tên riêng biệt cho các người thuê khác nhau để cung cấp sự cô lập và thực thi hạn ngạch. Phân đoạn mạng (VLAN, NIC riêng biệt) có thể tăng cường hơn nữa bảo mật và cô lập hiệu suất.

4. NVMe/TCP xử lý lỗi mạng như thế nào? NVMe/TCP, giống như bất kỳ giao thức dựa trên TCP nào, dựa vào các cơ chế đáng tin cậy của TCP. Để có tính khả dụng cao, đa đường là rất quan trọng. Bằng cách cấu hình nhiều đường dẫn mạng (ví dụ: nhiều NIC, nhiều IP đích), multipathd trên trình khởi tạo có thể tự động chuyển đổi dự phòng sang một đường dẫn thay thế nếu một đường dẫn bị lỗi, đảm bảo truy cập liên tục vào bộ lưu trữ. Đặc tả NVMe-oF cũng bao gồm các cơ chế chuyển đổi dự phòng cấp bộ điều khiển.

5. Những cân nhắc về bảo mật đối với NVMe/TCP là gì? NVMe/TCP, theo mặc định, không bao gồm xác thực hoặc mã hóa mạnh mẽ. Đối với các triển khai sản xuất, điều quan trọng là phải:

   • Cô lập mạng: Đặt lưu lượng NVMe/TCP trên một phân đoạn mạng chuyên dụng, cô lập (VLAN).
   • Danh sách trắng IP: Cấu hình tường lửa đích để chỉ chấp nhận các kết nối từ các IP trình khởi tạo được ủy quyền.
   • TLS/DTLS: Đặc tả NVMe-oF hỗ trợ TLS/DTLS để mã hóa và xác thực, mặc dù việc triển khai có thể khác nhau. Đảm bảo đích và trình khởi tạo NVMe/TCP của bạn hỗ trợ và được cấu hình cho TLS nếu cần mã hóa dữ liệu đang truyền.
   • Xác thực cấp máy chủ: Một số triển khai có thể hỗ trợ các cơ chế xác thực cấp máy chủ như SASL.