Google Kubernetes Engine에서 성능 테스트

여러 GKE 클라이언트에서 Google Kubernetes Engine (GKE) 워크로드의 읽기 및 쓰기 성능을 테스트하려면 IOR 벤치마크 도구를 사용하세요. 다음 안내에서는 클라이언트 설정을 자동화하고 Kubernetes 포드 간에 비밀번호가 없는 SSH를 통해 mpirun으로 IOR을 사용하여 집계 I/O를 테스트하는 방법을 보여줍니다.

기본 요건

• 이미 프로비저닝된 Managed Lustre 인스턴스

• Google Artifact Registry 또는 Container Registry로 푸시하도록 구성되고 인증된 로컬 Docker 환경 (인증 방법 참고)

• 네트워크의 mtu 값이 다음에 설정되어 있는지 확인합니다8896.

GKE 클러스터 만들기

성능을 테스트하려면 Managed Lustre CSI 드라이버가 사용 설정된 GKE 클러스터가 필요합니다. 고성능 스토리지 워크로드의 경우 컴퓨팅 최적화 머신 계열 (예: c2 또는 c3) 및 TIER_1 네트워킹으로 GKE 노드 풀을 구성합니다.

다음 명령어를 실행하여 성능 테스트에 최적화된 표준 GKE 클러스터를 만듭니다.

gcloud container clusters create CLUSTER_NAME \
    --zone=ZONE \
    --machine-type=MACHINE_TYPE \
    --addons=LustreCsiDriver \
    --network-performance-configs=total-egress-bandwidth-tier=TIER_1 \
    --network=NETWORK \
    --num-nodes=NUM_NODES

• ZONE 및 NETWORK를 특정 배포 값으로 바꿉니다. 클러스터는 Managed Lustre 인스턴스와 동일한 VPC 네트워크에 있어야 합니다.

• MACHINE_TYPE을 선택합니다. 최고의 처리량을 얻기 위해 머신 유형을 선택하는 방법에 대한 자세한 내용은 성능 고려사항 을 참고하세요.

• 머신 유형이 TIER_1 네트워킹을 지원하지 않으면 명령어에서 --network-performance-configs 행을 삭제합니다.

• 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).

참고: 기존 클러스터를 사용하거나 Autopilot을 선호하는 경우 Managed Lustre CSI 드라이버가 사용 설정되어 있는지 확인합니다. 자세한 내용은 Managed Lustre CSI 드라이버 구성 을 참고하세요.

IOR Docker 이미지 만들기

OpenMPI 및 IOR이 설치된 컨테이너 이미지를 빌드합니다. 더 나은 성능을 위해 비동기 I/O (AIO) 지원으로 IOR을 컴파일합니다.

1. 로컬에서 Dockerfile이라는 파일을 만듭니다.

   FROM ubuntu:22.04
   
   # Prevent interactive prompts during installation
   ENV DEBIAN_FRONTEND=noninteractive
   
   # Install dependencies, SSH, and required Autotools packages
   RUN apt-get update && apt-get install -y \
     openssh-server \
     openmpi-bin \
     libopenmpi-dev \
     wget \
     git \
     make \
     gcc \
     g++ \
     automake \
     autoconf \
     libtool \
     pkg-config \
     libaio-dev \
     sudo \
     && rm -rf /var/lib/apt/lists/*
   
   # Build IOR from source (version 4.0.0) with Asynchronous I/O (AIO) support
   RUN git clone -b 4.0.0 https://github.com/hpc/ior /tmp/ior \
     && cd /tmp/ior \
     && ./bootstrap \
     && ./configure --disable-dependency-tracking --with-aio \
     && make -j"$(nproc)" \
     && make install \
     && rm -rf /tmp/ior
   
   # Configure SSH for OpenMPI passwordless communication
   RUN mkdir /var/run/sshd
   RUN echo 'root:root' | chpasswd
   RUN sed -i 's/^#PermitRootLogin.*/PermitRootLogin yes/' /etc/ssh/sshd_config
   RUN sed -i 's/^#PasswordAuthentication.*/PasswordAuthentication yes/' /etc/ssh/sshd_config
   
   # SSH login fix so user isn't kicked out after container initialization
   RUN sed 's@session\s*required\s*pam_loginuid.so@session optional pam_loginuid.so@g' -i /etc/pam.d/sshd
   
   EXPOSE 22
   CMD ["/usr/sbin/sshd", "-D"]
   

2. 이 이미지를 원하는 컨테이너 레지스트리에 빌드하고 푸시합니다. 이 문서의 안내에서는 Artifact Registry를 사용합니다.

   export IMAGE_TAG="gcr.io/PROJECT_ID/lustre-ior-benchmark:latest"
   docker build -t $IMAGE_TAG .
   docker push $IMAGE_TAG
   

MPI용 비밀번호가 없는 SSH 키 생성

OpenMPI에는 비밀번호가 없는 SSH를 사용한 노드 간 통신이 필요합니다. SSH 키를 만들고 Kubernetes 보안 비밀에 저장합니다.

1. RSA 키를 생성합니다.

   ssh-keygen -t rsa -b 4096 -C "mpi-user" -N '' -f "./id_rsa"
   

2. Kubernetes 보안 비밀을 만듭니다.

   kubectl create secret generic mpi-ssh-secret \
     --from-file=id_rsa=./id_rsa \
     --from-file=id_rsa.pub=./id_rsa.pub \
     --from-file=authorized_keys=./id_rsa.pub
   

영구 볼륨 및 클레임 만들기

정적 프로비저닝 을 사용하여 GKE 포드를 Managed Lustre 인스턴스에 연결합니다.

1. lustre-pv.yaml이라는 파일을 만듭니다. 다음을 바꿉니다.

   • CAPACITY를 인스턴스의 스토리지 용량(GiB)으로 바꿉니다.
   • EXTENDED_LUSTRE_ID를 PROJECT_ID/ZONE/INSTANCE_NAME 형식의 Managed Lustre 식별자로 바꿉니다. 예를 들어 project-123/us-west1-a/my-lustre-instance입니다.
   • LUSTRE_IP를 인스턴스의 마운트 IP 주소로 바꿉니다.
   • FS_NAME을 인스턴스의 파일 시스템 이름으로 바꿉니다.

   이러한 값은 gcloud lustre instances describe 명령어로 검색할 수 있습니다.

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: my-lustre-pv
   spec:
     storageClassName: ""
     claimRef:
       name: my-lustre-pvc
       namespace: default
     accessModes:
       - ReadWriteMany
     capacity:
       storage: CAPACITYGi   # retain `Gi` suffix
     persistentVolumeReclaimPolicy: Retain
     volumeMode: Filesystem
     csi:
       driver: lustre.csi.storage.gke.io
       volumeHandle: EXTENDED_LUSTRE_ID   # project-name/zone/instance-name
       volumeAttributes:
         ip: LUSTRE_IP
         filesystem: FS_NAME
   ---
   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: my-lustre-pvc
   spec:
     storageClassName: ""
     volumeName: my-lustre-pv
     accessModes:
       - ReadWriteMany
     resources:
       requests:
         storage: CAPACITYGi
   

2. 매니페스트를 적용합니다.

   kubectl apply -f lustre-pv.yaml
   

MPI 작업자 배포

여러 노드에서 IOR 태스크를 확장하려면 벤치마크 이미지를 사용하여 StatefulSet를 배포합니다.

1. mpi-workers.yaml이라는 파일을 만듭니다. PROJECT_ID를 지정하고 클러스터의 노드 수로 설정합니다.NUM_NODES

   apiVersion: v1
   kind: Service
   metadata:
     name: mpi-workers
     labels:
       app: mpi-worker
   spec:
     clusterIP: None
     selector:
       app: mpi-worker
     ports:
     - port: 22
       name: ssh
   ---
   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
     name: mpi-worker
   spec:
     serviceName: "mpi-workers"
     replicas: NUM_NODES
     selector:
       matchLabels:
         app: mpi-worker
     template:
       metadata:
         labels:
           app: mpi-worker
       spec:
         tolerations:
           - operator: "Exists"
         containers:
           - name: mpi-worker
             image: gcr.io/PROJECT_ID/lustre-ior-benchmark:latest
             command: ["/bin/sh", "-c"]
             args:
               - >-
                 mkdir -p /var/run/sshd &&
                 ssh-keygen -A &&
                 mkdir -p /root/.ssh &&
                 echo "Host *" > /root/.ssh/config &&
                 echo "    StrictHostKeyChecking no" >> /root/.ssh/config &&
                 echo "    UserKnownHostsFile=/dev/null" >> /root/.ssh/config &&
                 cp /mnt/mpi-ssh-keys/id_rsa /root/.ssh/id_rsa &&
                 cp /mnt/mpi-ssh-keys/id_rsa.pub /root/.ssh/id_rsa.pub &&
                 cp /mnt/mpi-ssh-keys/authorized_keys /root/.ssh/authorized_keys &&
                 chmod 700 /root/.ssh &&
                 chmod 600 /root/.ssh/* &&
                 exec /usr/sbin/sshd -D
             ports:
               - containerPort: 22
             volumeMounts:
               - name: lustre-mount
                 mountPath: /lustre
               - name: ssh-key-secret
                 mountPath: /mnt/mpi-ssh-keys
                 readOnly: true
         volumes:
           - name: lustre-mount
             persistentVolumeClaim:
               claimName: my-lustre-pvc
           - name: ssh-key-secret
             secret:
               secretName: mpi-ssh-secret
   

2. 매니페스트를 적용합니다.

   kubectl apply -f mpi-workers.yaml
   

IOR 벤치마크 실행

첫 번째 포드 (mpi-worker-0)에서 벤치마크를 시작하여 헤드 노드로 처리합니다.

1. 작업자의 내부 IP 주소가 포함된 호스트 파일을 생성하고 헤드 노드에 복사합니다.

   kubectl get pods -l app=mpi-worker -o jsonpath='{range .items[*]}{.status.podIP}{"\n"}{end}' > hosts.txt
   kubectl cp hosts.txt mpi-worker-0:/root/hostfile
   

2. 헤드 포드 내에서 bash 세션을 엽니다.

   kubectl exec -it mpi-worker-0 -- /bin/bash
   

3. 포드 내에서 테스트 디렉터리를 만듭니다.

   mkdir -p /lustre/test
   

4. 테스트 변수를 정의합니다.

   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 사이로 설정하면 최고의 네트워크 처리량이 생성됩니다.

5. 벤치마크 명령어를 실행합니다.

   쓰기 처리량

   이 명령어는 최대 정상 상태 처리량을 테스트하기 위해 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에 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

   이 테스트는 작은 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). 이 "stonewalling"은 벤치마크를 균등하게 종료하여 실제 정상 상태 측정을 캡처합니다.
   • -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 형식으로 요약 데이터를 내보내도록 지시할 수 있습니다.

이렇게 하려면 -O 플래그를 ior 명령어 문자열 끝에 추가합니다.

-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 볼륨에서 테스트 파일을 삭제합니다.

   kubectl exec mpi-worker-0 -- rm -rf /lustre/test
   

2. GKE 클러스터를 삭제합니다.

   gcloud container clusters delete CLUSTER_NAME --zone=ZONE
   

   클러스터를 삭제하면 GKE 포드, Kubernetes 보안 비밀, 영구 볼륨 클레임도 삭제됩니다.

3. 벤치마크 Docker 이미지를 푸시했고 더 이상 필요하지 않은 경우 저장소에서 이미지를 삭제합니다.

   gcloud container images delete gcr.io/PROJECT_ID/lustre-ior-benchmark:latest --force-delete-tags
   

4. 이 테스트를 위해 Managed Lustre 인스턴스를 만들었으나 더 이상 필요하지 않은 경우 삭제합니다.

   gcloud lustre instances delete INSTANCE_ID --location=LOCATION
   

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

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