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를 지정합니다. 지원되는 값은 다음과 같습니다.

    OS 이미지 계열 (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 네트워킹이 사용 설정된 머신의 경우 VM 계열 및 CPU 수에 따라 단일 머신이 25~200Gbps (~3,000~25,000MBps)를 푸시할 수 있습니다. 표준 인스턴스의 경우 이그레스는 일반적으로 vCPU당 약 2Gbps로 제한됩니다.

    예를 들어 Managed Lustre 인스턴스 용량이 이론적 처리량 100,000MBps를 생성하는 경우 이를 포화시키려면 집계 클라이언트 이그레스가 120,000MBps (100,000 * 1.2)여야 합니다.

    • 표준 인스턴스 사용: 각 클라이언트 머신의 게시된 이그레스가 2,000MBps인 경우 클라이언트를 60개 이상 프로비저닝해야 합니다 (120,000 / 2,000).
    • Tier 1 네트워킹 사용: 각 클라이언트 머신의 게시된 이그레스가 10,000MBps (~80Gbps)인 경우 클라이언트를 12개 이상 프로비저닝해야 합니다(120,000 / 10,000).

키 및 파일 복사

클라이언트 머신이 시작 스크립트를 완료할 때까지 기다리는 동안 다음 명령어를 로컬로 실행하여 노드 간 통신을 위해 모든 노드를 자동으로 구성합니다.

  1. MPI 호스트 파일의 클라이언트 머신 비공개 IP 주소와 클라이언트 머신에 대한 SSH 및 SCP 액세스의 공개 IP 주소를 저장합니다.

    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초 동안 지속적으로 쓰기를 실행하여 최대 정상 상태 처리량을 테스트합니다. 작업당 파일 크기는 60초 타이머가 만료될 때까지 작업이 쓰기를 계속하도록 임의로 큰 50TiB 상한으로 설정됩니다.

    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)는 쓰기 단계의 형상과 일치하도록 50TiB로 설정되지만 -O stoneWallingWearOut=1 플래그는 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 \
  --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

    이 테스트는 작은 4KiB 전송 크기와 8GiB 작업당 파일 크기를 사용하여 파일 시스템이 처리할 수 있는 최대 초당 입출력 작업 수 (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

    스파스 파일에서 읽는 것을 방지하기 위해 이 테스트에서는 두 가지 명령어를 사용합니다. 먼저 4MiB 전송 크기와 8GiB 작업당 파일 크기를 사용하여 솔리드 파일을 만드는 쓰기를 실행한 후 실제 4KiB 무작위 읽기 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초 동안 지속적으로 쓰기를 실행하여 최대 정상 상태 처리량을 테스트합니다. 작업당 파일 크기는 60초 타이머가 만료될 때까지 작업이 쓰기를 계속하도록 임의로 큰 50TiB 상한으로 설정됩니다.

    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)는 쓰기 단계의 형상과 일치하도록 50TiB로 설정되지만 -O stoneWallingWearOut=1 플래그는 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" \
  --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

    이 테스트는 작은 4KiB 전송 크기와 8GiB 작업당 파일 크기를 사용하여 파일 시스템이 처리할 수 있는 최대 초당 입출력 작업 수 (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

    스파스 파일에서 읽는 것을 방지하기 위해 이 테스트에서는 두 가지 명령어를 사용합니다. 먼저 4MiB 전송 크기와 8GiB 작업당 파일 크기를 사용하여 솔리드 파일을 만드는 쓰기를 실행한 후 실제 4KiB 무작위 읽기 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: 노드 간 실행 안정성을 개선하기 위해 트리 기반 데몬 생성을 사용 중지합니다.
    • --mca opal_set_max_sys_limits 1: 시스템 한도 (예: 최대 열린 파일 수)를 허용되는 최대값으로 자동으로 설정하려고 시도합니다.
    • --mca plm_rsh_num_concurrent: 작업자 데몬을 실행할 때 동시 SSH 연결 mpirun이 사용할 최대 수를 설정합니다.
    • --mca plm_rsh_args ...: 엄격한 호스트 키 확인을 우회하여 대화형 SSH 프롬프트가 MPI 프로세스 실행을 중단하지 않도록 합니다.
    • --prefix ...: 작업자 노드가 필요한 데몬(orted)을 찾을 수 있도록 Rocky Linux 및 RHEL의 OpenMPI 설치 경로를 명시적으로 정의합니다.
    • --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, IOPS의 경우 4k).
    • -b: 테스트가 시간 제한 실행 중에 페이로드 데이터가 부족하지 않도록 프로세스당 대상 블록 크기 (예: 처리량의 경우 50t, 8g IOPS의 경우)를 설정합니다.
    • -D: 테스트 실행 시간(예: 60 또는 45)을 특정 초로 제한합니다. 이 '스톤월링'은 벤치마크를 균등하게 종료하여 실제 정상 상태 측정을 캡처합니다.
    • -O stoneWallingWearOut=1: 모든 동시 스레드가 전체 기간 동안 지속적인 쓰기 부하를 계속 생성하도록 하여 더 빠른 스레드가 조기에 완료되고 전반적인 네트워크 압력이 떨어지는 것을 방지합니다.
    • -O stoneWallingStatusFile=<path>: 쓰기 단계가 끝나면 상태 확인 파일을 작성합니다. 후속 읽기 단계에서는 이 파일을 사용하여 성공적으로 커밋된 블록만 읽으므로 읽기 중에 null 포인터 오류가 발생하지 않습니다.
    • -o: Managed Lustre 파일 시스템의 테스트 파일 경로입니다.

결과 보기

벤치마크가 완료되면 모든 클라이언트 VM 또는 포드의 집계 성능 측정항목이 터미널에 직접 표시됩니다. 출력 하단의 결과 표에서 최대 처리량 또는 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당 500MBps 등급의 216,000GiB 인스턴스는 수학적으로 105,469MBps 의 처리량을 제공합니다 ((216000 / 1024) * 500).

관찰된 최대 처리량은 항상 파일 시스템의 프로비저닝된 처리량 용량 또는 클라이언트 머신의 결합된 네트워크 이그레스 한도 중 더 낮은 값으로 제한됩니다.

벤치마크 숫자가 이론적 속도에 도달하지 못하는 일반적인 이유는 다음과 같습니다.

  • TCP/IP 오버헤드: 표준 네트워크 캡슐화 및 패킷 헤더는 원시 대역폭의 약 5~10% 를 사용합니다. 수학적 최대값에는 이 오버헤드가 포함되지만 IOR 벤치마크는 디스크에 작성된 원시 페이로드만 측정합니다.

  • 클라이언트 네트워크 한도: 클라이언트 머신에는 엄격한 이그레스 대역폭 상한이 있습니다. 소수의 클라이언트 또는 노드 또는 Tier 1 네트워킹이 사용 설정되지 않은 머신 유형을 사용하는 경우 Managed Lustre 파일 시스템이 한도에 도달하기 전에 클라이언트가 벤치마크를 제한합니다.

  • MPI 컨텍스트 전환: PROCESSES_PER_NODE가 클라이언트 머신의 실제 코어 수보다 높게 설정된 경우 CPU 경합 및 컨텍스트 전환 오버헤드로 인해 벤치마크의 I/O 성능이 인위적으로 저하됩니다.

  • 직접 I/O 누락: --posix.odirect 플래그가 생략되면 데이터가 클라이언트의 RAM 페이지 캐시를 통과합니다. 이렇게 하면 실제 네트워크 스토리지 성능을 마스크하는 메모리 병목 현상과 CPU 오버헤드가 발생합니다.

정리

이 페이지에서 사용한 리소스 비용이 계정에 청구되지 않도록 하려면 다음 단계를 수행합니다. Google Cloud

  1. Managed 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

일반적인 벤치마크 병목 현상 문제 해결

벤치마크 결과가 예상 스토리지 성능 등급보다 훨씬 낮은 경우 일반적인 병목 현상 문제 해결을 참조하세요.