使用 Compute Engine 用戶端進行效能測試

本頁說明如何使用 Compute Engine 用戶端，測試 Google Cloud Managed Lustre 執行個體的效能。這份指南提供相關操作說明，教您如何使用 fio 評估單一用戶端的效能，以及使用 IOR 基準測試工具匯總多個用戶端的效能。

評估單一用戶端成效

如要測試單一 Compute Engine 用戶端的讀取和寫入效能，請使用 fio (彈性 I/O 測試工具) 指令列工具。

  1. 安裝 fio：

    Rocky 8 

    sudo dnf install fio -y

    Ubuntu 20.04 和 22.04 

    sudo apt update
sudo install fio

  2. 執行下列指令：

    fio --ioengine=libaio --filesize=32G --ramp_time=2s \
--runtime=5m --numjobs=16 --direct=1 --verify=0 --randrepeat=0 \
--group_reporting --directory=/lustre --buffer_compress_percentage=50 \
--name=read --blocksize=1m --iodepth=64 --readwrite=read

這項測試大約 5 分鐘就能完成，完成後，系統會顯示結果。視設定而定，總處理量最高可達 VM 的最大網路速度，且每 TiB 可達數千 IOPS。

評估多重客戶成效

如要從多個 Compute Engine 用戶端測試 Managed Lustre 的讀取和寫入效能，請使用 IOR 基準測試工具。下列操作說明會介紹如何自動設定用戶端，以及如何使用 IOR 測試多部用戶端機器的匯總 I/O。IOR 使用MPI (訊息傳遞通訊協定)，讓多部用戶端電腦彼此協調。

開始前，請確認網路的 mtu 值已設為 8896。

設定環境變數並產生 SSH 金鑰

部署叢集前，請在本機電腦上產生 SSH 金鑰。這個金鑰會在建立期間分配給用戶端電腦，以啟用 MPI 的無密碼通訊。

export SSH_USER="lustre-user"
export CLIENT_PREFIX="lustre-client"

# Generate an SSH key for the specified user
ssh-keygen -t rsa -b 4096 -C "${SSH_USER}" -N '' -f "./id_rsa"
chmod 600 "./id_rsa"

# Create a metadata file formatted for Google Cloud
echo "${SSH_USER}:$(cat "./id_rsa.pub") ${SSH_USER}" > "./keys.txt"

建立開機指令碼

將下列內容儲存到本機電腦上名為 install-ior.sh 的檔案。這項指令碼會偵測作業系統、等待啟動鎖定解除、安全地安裝 Lustre 用戶端和依附元件、編譯 IOR 的穩定版本，以及掛接 Managed Lustre 檔案系統。

將 LUSTRE_IP 替換為 Managed Lustre 執行個體的 IP 位址，並將 FS_NAME 替換為檔案系統名稱。

#!/bin/bash
source /etc/os-release

if [[ "$ID" == "ubuntu" ]]; then
    # Ubuntu
    # Wait for apt lock
    while fuser /var/lib/dpkg/lock-frontend >/dev/null 2>&1; do sleep 5; done

    # Configure Artifact Registry repo for Ubuntu
    curl -fsSL https://us-apt.pkg.dev/doc/repo-signing-key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/us-apt-pkg-dev.gpg

    if [[ "$VERSION_ID" == "22.04" ]]; then
        REPO_NAME="lustre-client-ubuntu-jammy"
    elif [[ "$VERSION_ID" == "24.04" ]]; then
        REPO_NAME="lustre-client-ubuntu-noble"
    fi

    echo "deb [signed-by=/usr/share/keyrings/us-apt-pkg-dev.gpg] https://us-apt.pkg.dev/projects/lustre-client-binaries $REPO_NAME main" | sudo tee /etc/apt/sources.list.d/lustre-client.list

    sudo apt-get update
    while ! sudo apt-get install -y lustre-client-modules-$(uname -r) lustre-client-utils openmpi-bin libopenmpi-dev make gcc g++ wget git automake autoconf libaio-dev; do
        sleep 5
    done
    sudo modprobe lustre
else
    # Red Hat / Rocky Linux
    while systemctl is-active --quiet dnf-makecache.service; do sleep 5; done

    if [[ "$ID" == "rocky" && "$VERSION_ID" == 8* ]]; then
        REPO="lustre-client-rocky-8"
    elif [[ "$ID" == "rocky" && "$VERSION_ID" == 9* ]]; then
        REPO="lustre-client-rocky-9"
    elif [[ "$ID" == "rhel" && "$VERSION_ID" == 9* ]]; then
        REPO="lustre-client-rocky-9"
    fi

    gcloud beta artifacts print-settings yum --repository=$REPO --location=us --project=lustre-client-binaries | sudo bash

    while ! sudo dnf -y --enablerepo=$REPO install kmod-lustre-client lustre-client; do sleep 5; done
    sudo modprobe lustre

    while ! sudo dnf install -y openmpi openmpi-devel make gcc gcc-c++ wget git automake autoconf libaio-devel; do sleep 5; done

    export PATH=$PATH:/usr/lib64/openmpi/bin
fi

# Build IOR from source
echo "Cloning repo: https://github.com/hpc/ior.git and building IOR"
pushd /tmp
git clone -b 4.0.0 https://github.com/hpc/ior
cd ior
./bootstrap
./configure --disable-dependency-tracking --with-aio
make clean
make -j"$(nproc)"
sudo make install
popd
echo "Finished building IOR"

# Mount the Managed Lustre file system
mkdir -p /lustre

if ! grep -q "/lustre" /etc/fstab; then
    echo "LUSTRE_IP@tcp:/FS_NAME /lustre lustre defaults,_netdev 0 0" >> /etc/fstab
fi

mount -a

部署用戶端電腦

執行下列指令，大量建立 Compute Engine 用戶端機器。

gcloud compute instances bulk create \
  --name-pattern="${CLIENT_PREFIX}-####" \
  --zone="ZONE" \
  --machine-type="MACHINE_TYPE" \
  --scopes="https://www.googleapis.com/auth/cloud-platform" \
  --network-interface=subnet=SUBNET,nic-type=GVNIC \
  --network-performance-configs=total-egress-bandwidth-tier=TIER_1 \
  --metadata-from-file=ssh-keys=./keys.txt,startup-script=install-ior.sh \
  --create-disk=auto-delete=yes,boot=yes,\
image-family=IMAGE_FAMILY,\
image-project=IMAGE_PROJECT,\
mode=rw,size=100,type=DISK_TYPE \
  --count NUM_NODES

  • 將 ZONE 和 SUBNET 替換為您的特定部署值。

  • 選擇MACHINE_TYPE。基準的整體效能取決於用戶端機型。如要瞭解如何選擇機型以獲得最佳處理量，請參閱效能考量。

  • 如果機型不支援 TIER_1 網路，請從指令中刪除 --network-performance-configs 行。

  • 將 DISK_TYPE 設為 hyperdisk-balanced (適用於世代名稱中含有 4 的機器類型，例如 c4a 或 n4) 或 pd-balanced。

  • 指定 IMAGE_FAMILY 和 IMAGE_PROJECT。 支援的值如下：

    作業系統 映像檔系列 (x86) 映像檔系列 (ARM) 映像檔專案
    HPC Rocky Linux 8 hpc-rocky-linux-8 不支援 cloud-hpc-image-public
    Rocky Linux 9 rocky-linux-9 rocky-linux-9-arm64 rocky-linux-cloud
    RHEL 9 rhel-9 rhel-9-arm64 rhel-cloud
    Ubuntu 22.04 LTS ubuntu-2204-lts ubuntu-2204-lts-arm64 ubuntu-os-cloud
    Ubuntu 24.04 LTS 不支援 ubuntu-2404-lts-arm64 ubuntu-os-cloud

  • 指定 NUM_NODES。如要達到檔案系統的飽和狀態，叢集的總網路容量應比檔案系統的佈建輸送量高出約 20%。

    啟用 Tier 1 網路的機器，單一機器可推送 25 Gbps 至 200 Gbps (約 3,000 至 25,000 MBps)，視 VM 系列和 CPU 數量而定。標準執行個體的輸出通常會設限，每個 vCPU 的上限約為 2 Gbps。

    舉例來說，如果 Managed Lustre 執行個體容量可產生 100,000 MBps 的理論處理量，則需要 120,000 MBps (100,000 * 1.2) 的匯總用戶端輸出，才能達到飽和狀態：

    • 使用標準執行個體：如果每部用戶端電腦的已發布輸出頻寬為 2,000 MBps，您應至少佈建 60 部用戶端電腦 (120,000 / 2,000)。
    • 使用第 1 層網路：如果每部用戶端機器的已發布輸出為 10,000 MBps (約 80 Gbps)，您應至少佈建 12 部用戶端 (120,000 / 10,000)。

複製金鑰和檔案

等待用戶端機器完成啟動指令碼時，請在本地執行下列指令，自動設定所有節點的節點間通訊。

  1. 儲存用戶端機器的私人 IP 位址 (適用於 MPI 主機檔案)，以及公開 IP 位址 (適用於 SSH 和 SCP 存取用戶端機器)：

    gcloud compute instances list --filter="name ~ '^${CLIENT_PREFIX}*'" --format="csv[no-heading](INTERNAL_IP)" > hosts.txt
gcloud compute instances list --filter="name ~ '^${CLIENT_PREFIX}*'" --format="csv[no-heading](EXTERNAL_IP)" > external_ips.txt

  2. 將私密金鑰複製到所有用戶端。這可讓工作站節點在基準測試期間安全地相互通訊：

    while IFS= read -r IP || [[ -n "$IP" ]]
do
  [[ -z "$IP" ]] && continue
  echo "Preparing and copying to ${SSH_USER}@${IP}..."
  # Ensure the .ssh directory exists
  ssh -i ./id_rsa -o StrictHostKeyChecking=no "${SSH_USER}@${IP}" "mkdir -p ~/.ssh && chmod 700 ~/.ssh"
  # Copy the file
  scp -i ./id_rsa -o StrictHostKeyChecking=no ./id_rsa "${SSH_USER}@${IP}:~/.ssh/id_rsa"
done < "./external_ips.txt"

  3. 指定頭部節點，並將主機檔案複製到該節點。這是指您執行基準測試的機器。

    export HEAD_NODE=$(head -n 1 ./external_ips.txt)
scp -i ./id_rsa -o "StrictHostKeyChecking=no" -o UserKnownHostsFile=/dev/null ./hosts.txt ${SSH_USER}@${HEAD_NODE}:~/hostfile

連線及驗證

  1. 連線至主要節點：

    ssh -i ./id_rsa -o "StrictHostKeyChecking=no" -o UserKnownHostsFile=/dev/null ${SSH_USER}@${HEAD_NODE}

  2. 請先確認開機指令碼已執行完畢，且檔案系統已成功掛接，再執行基準測試。

    如要查看開機指令碼記錄，請按照下列步驟操作：

    sudo journalctl -u google-startup-scripts.service -f

    如要確認檔案系統已掛接，請執行下列指令：

    df -h | grep lustre

    如果未列出檔案系統，請再等待幾分鐘，讓背景安裝指令碼完成作業。掛接後，即可透過絕對路徑 /lustre 存取。

執行 IOR 基準測試

  1. 僅限 Rocky Linux 和 RHEL：從頭節點載入 OpenMPI 模組。

    if [ -f /etc/profile.d/modules.sh ]; then
    source /etc/profile.d/modules.sh
    module load mpi/openmpi-$(arch)
fi

  2. 建立測試目錄並取得擁有權：

    sudo mkdir -p /lustre/test
sudo chown -R $USER:$USER /lustre/test

  3. 定義測試變數：

    export NUM_NODES="NUM_NODES"
export PROCESSES_PER_NODE="PROCESSES_PER_NODE"
export NUM_PROCESSES=$(( NUM_NODES * PROCESSES_PER_NODE ))

    其中：

    • NUM_NODES：參與測試的用戶端電腦總數。
    • PROCESSES_PER_NODE：要在每個個別用戶端電腦上執行的 MPI 等級數量。建議您先將此值設為與用戶端電腦上的實體核心數量相同 (或 vCPU 數量的一半)。對於高效能機器類型，將此值設為 8 和 16 之間，通常可產生最佳網路處理量。如果設定過高，可能會導致環境切換負荷過大，並降低基準效能。

  4. 執行指令來啟動基準測試：

    Rocky Linux 和 RHEL

    寫入總處理量

    這項指令會持續寫入 60 秒，以測試尖峰穩態總處理量。每個工作的檔案大小上限設為任意大的 50 TiB，讓工作持續寫入資料，直到 60 秒計時器到期為止。

    mpirun \
  --allow-run-as-root \
  --mca plm_rsh_no_tree_spawn 1 \
  --mca opal_set_max_sys_limits 1 \
  --mca plm_rsh_num_concurrent ${NUM_NODES} \
  --mca plm_rsh_args "-o StrictHostKeyChecking=no" \
  --prefix /usr/lib64/openmpi \
  --npernode ${PROCESSES_PER_NODE} \
  --np ${NUM_PROCESSES} \
  --hostfile ~/hostfile \
  /usr/local/bin/ior \
  -a AIO \
  --posix.odirect \
  -F -g -v -w -k \
  -t 4m -b 50t \
  -D 60 \
  -O stoneWallingWearOut=1 \
  -O stoneWallingStatusFile=/lustre/test/ior-easy.stonewall \
  -o /lustre/test/ior_file

    讀取總處理量

    這個階段會讀回在 60 秒寫入處理量測試期間成功寫入的資料量。雖然每個工作的檔案大小 (-b) 設為 50 TiB，與寫入階段的幾何結構相符，但 -O stoneWallingWearOut=1 標記會指示 IOR 在達到 stonewall 狀態檔案中記錄的確切資料界線時，立即停止讀取。

    mpirun \
  --allow-run-as-root \
  --mca plm_rsh_no_tree_spawn 1 \
  --mca opal_set_max_sys_limits 1 \
  --mca plm_rsh_num_concurrent ${NUM_NODES} \
  --mca plm_rsh_args "-o StrictHostKeyChecking=no" \
  --prefix /usr/lib64/openmpi \
  --npernode ${PROCESSES_PER_NODE} \
  --np ${NUM_PROCESSES} \
  --hostfile ~/hostfile \
  /usr/local/bin/ior \
  -a AIO \
  --posix.odirect \
  -F -g -v -r -k \
  -t 4m -b 50t \
  -D 60 \
  -O stoneWallingWearOut=1 \
  -O stoneWallingStatusFile=/lustre/test/ior-easy.stonewall \
  -o /lustre/test/ior_file

    寫入 IOPS

    這項測試會使用 4 KiB 的小型傳輸大小，以及每個工作 8 GiB 的檔案大小，測量檔案系統可處理的每秒最大輸入/輸出作業數 (IOPS)。

    mpirun \
  --allow-run-as-root \
  --mca plm_rsh_no_tree_spawn 1 \
  --mca opal_set_max_sys_limits 1 \
  --mca plm_rsh_num_concurrent ${NUM_NODES} \
  --mca plm_rsh_args "-o StrictHostKeyChecking=no" \
  --prefix /usr/lib64/openmpi \
  --np ${NUM_PROCESSES} \
  --oversubscribe \
  --map-by node \
  --bind-to socket \
  --hostfile ~/hostfile \
  /usr/local/bin/ior \
  -e \
  -t 4k \
  -b 8g \
  -s 1 \
  -a AIO \
  --posix.odirect \
  --aio.max-pending=256 \
  -w \
  -F \
  -z \
  -Q 1 \
  -G 1745405099 \
  -D 45 \
  -O stoneWallingWearOut=1 \
  -o /lustre/test/ior-random

    讀取 IOPS

    為避免從稀疏檔案讀取資料，這項測試會使用兩項指令：先寫入資料，以 4 MiB 的傳輸大小建立實體檔案，每個工作檔案的大小為 8 GiB，然後執行實際的 4 KiB 隨機讀取 IOPS 測試。

    1. 建立要讀取的檔案：

      mpirun \
  --allow-run-as-root \
  --mca plm_rsh_no_tree_spawn 1 \
  --mca opal_set_max_sys_limits 1 \
  --mca plm_rsh_num_concurrent ${NUM_NODES} \
  --mca plm_rsh_args "-o StrictHostKeyChecking=no" \
  --prefix /usr/lib64/openmpi \
  --npernode ${PROCESSES_PER_NODE} \
  --np ${NUM_PROCESSES} \
  --oversubscribe \
  --map-by node \
  --bind-to socket \
  --hostfile ~/hostfile \
  /usr/local/bin/ior \
  -a AIO \
  --posix.odirect \
  -w \
  -F \
  -k \
  -t 4m \
  -b 8g \
  -s 1 \
  -Q 1 \
  -G 1745405099 \
  -o /lustre/test/ior_rand_read

    2. 執行 IOR 讀取測試：

      mpirun \
  --allow-run-as-root \
  --mca plm_rsh_no_tree_spawn 1 \
  --mca opal_set_max_sys_limits 1 \
  --mca plm_rsh_num_concurrent ${NUM_NODES} \
  --mca plm_rsh_args "-o StrictHostKeyChecking=no" \
  --prefix /usr/lib64/openmpi \
  --oversubscribe \
  --map-by node \
  --bind-to socket \
  --npernode ${PROCESSES_PER_NODE} \
  --np ${NUM_PROCESSES} \
  --hostfile ~/hostfile \
  /usr/local/bin/ior \
  -a AIO \
  --posix.odirect \
  --aio.max-pending 256 \
  -r \
  -F \
  -z \
  -t 4k \
  -b 8g \
  -s 1 \
  -Q 1 \
  -G 1745405099 \
  -D 45 \
  -O stoneWallingWearOut=1 \
  -o /lustre/test/ior_rand_read

    Ubuntu

    寫入總處理量

    這項指令會持續寫入 60 秒，以測試尖峰穩態總處理量。每個工作的檔案大小上限設為任意大的 50 TiB，讓工作持續寫入資料，直到 60 秒計時器到期為止。

    mpirun \
  --allow-run-as-root \
  --mca plm_rsh_no_tree_spawn 1 \
  --mca opal_set_max_sys_limits 1 \
  --mca plm_rsh_num_concurrent ${NUM_NODES} \
  --mca plm_rsh_args "-o StrictHostKeyChecking=no" \
  --npernode ${PROCESSES_PER_NODE} \
  --np ${NUM_PROCESSES} \
  --hostfile ~/hostfile \
  /usr/local/bin/ior \
  -a AIO \
  --posix.odirect \
  -F -g -v -w -k \
  -t 4m -b 50t \
  -D 60 \
  -O stoneWallingWearOut=1 \
  -O stoneWallingStatusFile=/lustre/test/ior-easy.stonewall \
  -o /lustre/test/ior_file

    讀取總處理量

    這個階段會讀回在 60 秒寫入處理量測試期間成功寫入的資料量。雖然每個工作的檔案大小 (-b) 設為 50 TiB，與寫入階段的幾何結構相符，但 -O stoneWallingWearOut=1 標記會指示 IOR 在達到 stonewall 狀態檔案中記錄的確切資料界線時，立即停止讀取。

    mpirun \
  --allow-run-as-root \
  --mca plm_rsh_no_tree_spawn 1 \
  --mca opal_set_max_sys_limits 1 \
  --mca plm_rsh_num_concurrent ${NUM_NODES} \
  --mca plm_rsh_args "-o StrictHostKeyChecking=no" \
  --npernode ${PROCESSES_PER_NODE} \
  --np ${NUM_PROCESSES} \
  --hostfile ~/hostfile \
  /usr/local/bin/ior \
  -a AIO \
  --posix.odirect \
  -F -g -v -r -k \
  -t 4m -b 50t \
  -D 60 \
  -O stoneWallingWearOut=1 \
  -O stoneWallingStatusFile=/lustre/test/ior-easy.stonewall \
  -o /lustre/test/ior_file

    寫入 IOPS

    這項測試會使用 4 KiB 的小型傳輸大小，以及每個工作 8 GiB 的檔案大小，測量檔案系統可處理的每秒最大輸入/輸出作業數 (IOPS)。

    mpirun \
  --allow-run-as-root \
  --mca plm_rsh_no_tree_spawn 1 \
  --mca opal_set_max_sys_limits 1 \
  --mca plm_rsh_num_concurrent ${NUM_NODES} \
  --mca plm_rsh_args "-o StrictHostKeyChecking=no" \
  --np ${NUM_PROCESSES} \
  --oversubscribe \
  --map-by node \
  --bind-to socket \
  --hostfile ~/hostfile \
  /usr/local/bin/ior \
  -e \
  -t 4k \
  -b 8g \
  -s 1 \
  -a AIO \
  --posix.odirect \
  --aio.max-pending=256 \
  -w \
  -F \
  -z \
  -Q 1 \
  -G 1745405099 \
  -D 45 \
  -O stoneWallingWearOut=1 \
  -o /lustre/test/ior-random

    讀取 IOPS

    為避免從稀疏檔案讀取資料，這項測試會使用兩項指令：先寫入資料，以 4 MiB 的傳輸大小建立實體檔案，每個工作檔案的大小為 8 GiB，然後執行實際的 4 KiB 隨機讀取 IOPS 測試。

    1. 建立要讀取的檔案：

      mpirun \
  --allow-run-as-root \
  --mca plm_rsh_no_tree_spawn 1 \
  --mca opal_set_max_sys_limits 1 \
  --mca plm_rsh_num_concurrent ${NUM_NODES} \
  --mca plm_rsh_args "-o StrictHostKeyChecking=no" \
  --npernode ${PROCESSES_PER_NODE} \
  --np ${NUM_PROCESSES} \
  --oversubscribe \
  --map-by node \
  --bind-to socket \
  --hostfile ~/hostfile \
  /usr/local/bin/ior \
  -a AIO \
  --posix.odirect \
  -w \
  -F \
  -k \
  -t 4m \
  -b 8g \
  -s 1 \
  -Q 1 \
  -G 1745405099 \
  -o /lustre/test/ior_rand_read

    2. 執行 IOR 讀取測試：

      mpirun \
  --allow-run-as-root \
  --mca plm_rsh_no_tree_spawn 1 \
  --mca opal_set_max_sys_limits 1 \
  --mca plm_rsh_num_concurrent ${NUM_NODES} \
  --mca plm_rsh_args "-o StrictHostKeyChecking=no" \
  --oversubscribe \
  --map-by node \
  --bind-to socket \
  --npernode ${PROCESSES_PER_NODE} \
  --np ${NUM_PROCESSES} \
  --hostfile ~/hostfile \
  /usr/local/bin/ior \
  -a AIO \
  --posix.odirect \
  --aio.max-pending 256 \
  -r \
  -F \
  -z \
  -t 4k \
  -b 8g \
  -s 1 \
  -Q 1 \
  -G 1745405099 \
  -D 45 \
  -O stoneWallingWearOut=1 \
  -o /lustre/test/ior_rand_read

    mpirun 標記如下：

    • --mca plm_rsh_no_tree_spawn 1：停用樹狀結構的 Daemon 產生，以提升節點的啟動可靠性。
    • --mca opal_set_max_sys_limits 1：自動嘗試將系統限制 (例如開啟的檔案數上限) 設為允許的最高值。
    • --mca plm_rsh_num_concurrent：設定啟動工作站 Daemon 時，mpirun 可使用的並行 SSH 連線數量上限。
    • --mca plm_rsh_args ...：略過嚴格的主機金鑰檢查，防止互動式 SSH 提示導致 MPI 程序啟動作業停滯。
    • --prefix ...：明確定義 Rocky Linux 和 RHEL 的 OpenMPI 安裝路徑，以便 worker 節點找到所需 Daemon (orted)。
    • --allow-run-as-root：允許 mpirun 以超級使用者身分執行。
    • --oversubscribe：允許 MPI 在節點上排程的程序數量，超過可用的實體核心數量。
    • --map-by node：以循環方式將 MPI 程序平均分配到可用節點。
    • --bind-to socket：將 MPI 程序繫結至實體 CPU 插槽，以最佳化記憶體存取和快取效能。
    • --npernode：每個節點的程序數量。
    • --np：要啟動的 MPI 程序總數。
    • --hostfile：指定包含要執行主機清單的檔案。

    ior 標記如下：

    • -a AIO --posix.odirect：使用非同步 I/O (AIO) 引擎，並結合 POSIX 直接 I/O。這會略過用戶端 RAM 頁面快取，並強制將並行非封鎖寫入作業直接傳送至儲存伺服器，確保基準測試測量的是實際網路儲存空間效能，而非記憶體緩衝區。
    • --aio.max-pending=256：決定每個程序中進行中的並行非同步 I/O 作業數量上限。
    • -C：重新排序工作，以獲得最佳讀取效能。
    • -F：每個程序一個檔案的模式。
    • -g：使用屏障分隔測試的寫入和讀取階段。
    • -v：輸出詳細記錄。
    • -w / -r：指示 IOR 執行寫入 (-w) 或讀取 (-r) 效能測試。
    • -k：防止 IOR 在寫入後刪除測試檔案，以便進行讀取測試。
    • -e：在寫入階段後執行 fsync，確保資料已提交至儲存硬碟。
    • -z：指示 IOR 執行隨機存取 I/O，而非循序存取。
    • -s 1：將區隔數量設為 1。
    • -Q 1：設定每個節點的任務偏移量，對齊任務，使基準座標在所有節點中正確對齊。
    • -G 1745405099：將隨機種子時間戳記硬式編碼，確保讀取階段產生的隨機檔案位移與寫入階段使用的完全相同。
    • -t：為每個 I/O 作業設定轉移大小 (例如 4m 代表總處理量，4k 代表 IOPS)。
    • -b：設定每個程序的目標區塊大小 (例如 50t 代表處理量，8g 代表 IOPS)，確保測試在計時執行期間不會用盡酬載資料。
    • -D：將測試執行時間限制為特定秒數 (例如 60 或 45)。這項「阻斷」作業會平均終止基準測試，以擷取真正的穩定狀態測量結果。
    • -O stoneWallingWearOut=1：強制所有並行執行緒在整個期間持續產生寫入負載，避免較快的執行緒提早完成，進而降低整體網路壓力。
    • -O stoneWallingStatusFile=<path>：在寫入階段結束時寫入狀態驗證檔案。後續的讀取階段會使用這個檔案，只讀取已成功提交的區塊，避免在讀取期間發生空指標錯誤。
    • -o：Managed Lustre 檔案系統中測試檔案的路徑。

查看結果

基準測試完成後，終端機就會直接顯示所有用戶端 VM 或 Pod 的匯總成效指標。在輸出內容底部尋找「結果」表格，即可查看最大輸送量或 IOPS。

重要指標

  • aggregate filesize：所有參與測試的用戶端在測試期間寫入或讀取的資料總量。

  • bw(MiB/s) / Max Write / Max Read：連續測試最重要的指標。這會顯示 Managed Lustre 檔案系統達成的總頻寬。

  • IOPS：隨機 I/O 測試最重要的指標。這會顯示每秒輸入/輸出作業數上限。

將結果匯出至檔案

如要以程式輔助方式剖析結果、將結果匯入資料庫，或儲存結果以供日後分析，可以指示 IOR 匯出 JSON 和 CSV 格式的摘要資料，而非僅將資料列印到螢幕上。

如要這麼做，請在 ior 指令字串結尾附加 -O 標記：

-O summaryFormat=JSON \
-O summaryFile=/lustre/test/perf-results/summary.json \
-O saveRankPerformanceDetailsCSV=/lustre/test/perf-results/details.csv

執行基準測試前，檔案系統中必須存在輸出目錄。

預期與實際效能

您可以根據檔案系統的佈建容量和效能層級，計算其數學最大處理量。由於儲存空間容量是以 GiB 為單位配置，而層級是以 TiB 為單位計費，因此您必須先轉換容量：

(Capacity GiB / 1024) * Tier MBps = 理論最高 MBps

舉例來說，在「每 TiB 500 MBps」層級中，216,000 GiB 的執行個體在數學上可提供 105,469 MBps 的處理量 ((216000 / 1024) * 500)。

觀察到的最大輸送量一律會受限於檔案系統的佈建輸送量容量，或用戶端機器的合併網路輸出限制，以較低者為準。

基準測試結果未達理論速度的常見原因包括：

  • TCP/IP 額外負荷：標準網路封裝和封包標頭會耗用約 5% 到 10% 的原始頻寬。您的數學最大值包含這項額外負荷，但 IOR 基準僅測量寫入磁碟的原始酬載。

  • 用戶端網路限制：用戶端電腦有嚴格的輸出頻寬上限。如果您使用少量用戶端或節點，或是未啟用第 1 層網路的機器類型，用戶端會在 Managed Lustre 檔案系統達到上限前，先限制基準。

  • MPI 內容切換：如果 PROCESSES_PER_NODE 設定值高於用戶端電腦上的實體核心數量，CPU 爭用和內容切換負擔會人為降低基準測試的 I/O 效能。

  • 缺少直接 I/O：如果省略 --posix.odirect 標記，資料會通過用戶端的 RAM 頁面快取。這會造成記憶體瓶頸和 CPU 負擔，掩蓋網路儲存空間的實際效能。

清除所用資源

如要避免系統向您的 Google Cloud 帳戶收取本頁面所用資源的費用，請按照下列步驟操作：

  1. 從受管理 Lustre 磁碟區刪除測試檔案：

    ssh -i ./id_rsa -o "StrictHostKeyChecking=no" -o UserKnownHostsFile=/dev/null ${SSH_USER}@${HEAD_NODE} "rm -rf /lustre/test"

  2. 刪除大量建立的 Compute Engine 用戶端機器：

    gcloud compute instances delete $(gcloud compute instances list \
  --filter="name~'^${CLIENT_PREFIX}-'" --format="value(name)" --zones="ZONE") \
  --zone="ZONE"

    或者，如果您知道確切名稱或想個別刪除：

    gcloud compute instances delete CLIENT_PREFIX-0001 CLIENT_PREFIX-0002 ... --zone=ZONE

  3. 如果您建立的是自訂圖片，可以按照下列步驟刪除：

    gcloud compute images delete CUSTOM_IMAGE_NAME

  4. 如果您是為了這項測試建立 Managed Lustre 執行個體，且不再需要該執行個體，請刪除：

    gcloud lustre instances delete INSTANCE_ID --location=LOCATION

排解常見的基準化瓶頸

如果基準測試結果遠低於預期的儲存空間效能層級，請參閱「排解常見瓶頸」。