성능에 대한 고려사항

이 페이지에서는 최상의 성능을 얻기 위해 Google Cloud Managed Lustre 환경을 구성하는 방법을 안내합니다.

각 성능 등급과 관련된 성능 수치를 보려면 성능 등급을 참고하세요.

용량 증가 후 성능

기존 인스턴스의 스토리지 용량을 늘리면 최대 처리량과 IOPS가 증가하고 메타데이터 성능도 증가할 수 있습니다.

새 데이터가 작성되고 추가 스토리지에 재배포됨에 따라 읽기 처리량 성능이 점진적으로 개선됩니다. 쓰기 처리량 성능은 즉시 증가합니다.

용량 증가로 프로비저닝된 처리량이 72GBps 추가되지 않으면 메타데이터 성능이 증가하지 않을 수 있습니다.

높은 용량 사용률

인스턴스의 스토리지 용량 사용률이 90%에 도달하면 인스턴스의 성능이 저하될 수 있습니다. Managed Lustre 인스턴스의 용량을 늘리는 것이 좋습니다 . 확장하기 전에 추가 할당량을 요청해야 할 수 있습니다.

`No space left on device` 오류가 표시되지만 인스턴스에 남은 용량이 표시되는 경우 `No space left on device` 오류를 참고하세요.

VPC 네트워크 최대 전송 단위 (MTU)

VPC 네트워크를 만들 때 mtu (최대 전송 단위 또는 이 네트워크에서 전송할 수 있는 최대 IP 패킷 크기) 값을 허용되는 최대 값인 8896으로 설정하면 기본값인 1460바이트에 비해 성능이 최대 10% 향상됩니다.

다음 명령어를 사용하여 네트워크의 현재 MTU 값을 확인할 수 있습니다.

gcloud compute networks describe NETWORK_NAME --format="value(mtu)"

네트워크가 생성된 후 네트워크의 MTU 값을 업데이트할 수 있지만 중요한 고려사항이 있습니다. 자세한 내용은 네트워크의 MTU 변경을 참고하세요.

Compute Engine 머신 유형

네트워크 처리량은 선택한 머신 유형에 따라 영향을 받을 수 있습니다. 일반적으로 최상의 처리량을 얻으려면 다음을 수행하세요.

  • vCPU의 수를 늘립니다. 인스턴스당 최대 이그레스 대역폭은 일반적으로 vCPU당 2Gbps이며 머신 유형 최대값까지입니다.
  • 더 높은 인그레스 및 이그레스 한도를 지원하는 머신 시리즈를 선택합니다. 예를 들어 Tier_1 네트워킹을 사용하는 C2 인스턴스는 최대 100Gbps의 이그레스 대역폭을 지원합니다. Tier_1 네트워킹을 사용하는 C3 인스턴스는 최대 200Gbps를 지원합니다.
  • 더 큰 머신 유형을 사용하여 VM당 Tier_1 네트워킹 성능을 사용 설정합니다.
  • Google Virtual NIC (gVNIC)를 사용합니다. gVNIC는 3세대 이상 머신 유형의 유일한 옵션입니다. Tier_1 네트워킹을 사용하는 경우 gVNIC가 필요합니다.

자세한 내용은 네트워크 대역폭을 참고하세요.

멀티 NIC 구성

Lustre의 기본 제공 멀티 레일 기능을 사용하면 클라이언트가 여러 네트워크 인터페이스 카드 (멀티 NIC)에 네트워크 트래픽을 스트라이핑할 수 있습니다. 이렇게 하면 대역폭이 집계되어 대용량 Managed Lustre 인스턴스를 포화시킵니다.

멀티 NIC를 구성하려면 다음을 수행해야 합니다.

  • 물리적 NIC가 여러 개 있는 머신 유형을 선택합니다.
  • 각 NIC의 서브넷을 만들고 각 NIC를 서브넷에 할당합니다.
  • Compute Engine 또는 GKE에서 연결할 때 멀티 NIC 단계를 따릅니다.

트래픽 균형 조정 확인

멀티 NIC를 구성한 후 데이터가 올바르게 균형 조정되는지 확인합니다.

Compute Engine

Managed Lustre 백엔드로 트래픽을 생성하는 동안 nload를 사용하여 구성된 네트워크 인터페이스 (예: eth0, eth1)를 모니터링하여 VM에서 직접 데이터 균형 조정을 확인합니다.

nload -m eth0 eth1

멀티 NIC 구성이 성공하면 구성된 모든 인터페이스에서 발신 비트 전송률이 거의 동일해야 합니다.

GKE

워크로드가 예약된 노드에 임시 네트워크 디버거 포드를 배포하여 워크로드의 네트워크 트래픽이 여러 NIC에서 균형 조정되는지 확인합니다.

  1. 워크로드가 예약된 노드를 식별합니다.

    kubectl get pod POD_NAME -o wide

    POD_NAME을 포드 이름으로 바꿉니다. 명령어 출력에서 NODE 열의 이름을 기록해 둡니다.

  2. 해당 노드에서 네트워크 디버거를 실행합니다.

    kubectl run multi-nic-debug --rm -i --tty --image=nicolaka/netshoot \
  --overrides='{"spec": {"hostNetwork": true, "nodeSelector": {"kubernetes.io/hostname": "NODE_NAME"}, "tolerations": [{"key": "nvidia.com/gpu", "operator": "Exists", "effect": "NoSchedule"}]}}' \
  -- /bin/bash -c "apk update && apk add nload && nload -m eth0 eth1"

    NODE_NAME을 이전 단계의 노드 이름으로 바꿉니다.

  3. 출력에서 eth0 및 eth1의 발신 열 비트 전송률을 분석합니다. 구성이 성공하면 비트 전송률이 거의 동일합니다. 출력은 다음과 비슷합니다.

    Device eth0 [10.1.0.50] (1/2):
==========================================================================
Incoming:                               Outgoing:
Curr: 1.63 MBit/s                       Curr: 1.46 GBit/s
Avg: 1.60 MBit/s                        Avg: 1.44 GBit/s
Min: 1.40 MBit/s                        Min: 1.25 GBit/s
Max: 1.64 MBit/s                        Max: 1.47 GBit/s
Ttl: 590.94 GByte                       Ttl: 405.19 GByte

Device eth1 [172.16.15.5] (2/2):
==========================================================================
Incoming:                               Outgoing:
Curr: 1.64 MBit/s                       Curr: 1.47 GBit/s
Avg: 1.62 MBit/s                        Avg: 1.44 GBit/s
Min: 1.42 MBit/s                        Min: 1.26 GBit/s
Max: 1.66 MBit/s                        Max: 1.47 GBit/s
Ttl: 587.68 GByte                       Ttl: 406.36 GByte

  4. Ctrl+C 를 눌러 디버거를 종료합니다.

일반적인 병목 현상 문제 해결

워크로드 성능이 Managed Lustre 성능 등급에 예상되는 것보다 훨씬 낮은 경우 다음과 같은 일반적인 문제를 확인하세요.

  • 클라이언트 머신 수 부족: 단일 클라이언트 머신은 자체 가상 CPU (vCPU) 및 단일 링크 네트워크 처리 한도로 인해 병목 현상이 발생합니다. 고처리량 등급을 포화시키려면 부하를 분산해야 합니다. 예를 들어 100,000MBps Managed Lustre 파일 시스템을 포화시키려면 일반적으로 병렬로 쓰는 표준 클라이언트 머신이 60대 이상 (또는 Tier 1 고대역폭 네트워킹을 사용하도록 구성된 클라이언트 머신 12대) 필요합니다. 모든 성능 등급의 최대 인스턴스 크기의 경우 Tier 1 고대역폭 네트워킹을 사용하도록 구성된 클라이언트 머신이 2,500대 이상 필요할 수 있습니다.

  • 이상적인 가상 프라이빗 클라우드 (VPC) MTU가 아님: 기본적으로 VPC 네트워크는 MTU 1460 (표준 이더넷 프레임)을 사용합니다. Managed Lustre와 같은 고성능 스토리지를 사용하려면 MTU가 8896인 점보 프레임을 구성해야 합니다. 표준 1460 MTU로 실행하면 CPU가 두 배 이상의 네트워크 패킷을 처리해야 하므로 CPU 오버헤드가 추가되고 최대 대역폭이 제한됩니다.

  • Tier 1 네트워크 대역폭 구성 누락: 많은 고성능 머신 유형에서 Tier 1 네트워크 대역폭을 명시적으로 선택해야 합니다.

    • Compute Engine 및 GKE Standard 노드 풀에서 생성 중에 --network-performance-configs=total-egress-bandwidth-tier=TIER_1 플래그를 사용합니다. 이 플래그가 없으면 VM 또는 노드가 더 낮은 기본 이그레스 한도로 제한될 수 있습니다.
    • GKE Autopilot에서는 이 플래그를 직접 지정하지 않습니다. 대신 포드 사양에서 노드 선택기를 사용하여 더 높은 대역폭을 지원하는 머신 시리즈 (예: c3)를 선택합니다.

    자세한 내용은 Compute Engine 머신 유형을 참고하세요.

  • 균형이 맞지 않는 Lustre 객체 스토리지 타겟 (OST) 사용: Managed Lustre는 파일 데이터를 여러 객체 스토리지 타겟 (OST)으로 분할합니다. 테스트 또는 워크로드가 단일 스트라이핑되지 않은 파일에 쓰거나 클라이언트 작업이 단일 OST를 과부하하는 패턴을 쓰는 경우 해당 OST가 병목 현상이 되고 나머지 파일 시스템은 유휴 상태가 됩니다. 이를 방지하려면 사용 가능한 모든 OST에 쓰기 페이로드를 균등하게 분산해야 합니다 (예: 벤치마크에서 프로세스당 파일 모드 사용).

  • 공유 네트워크 대역폭 경합: 클라이언트 머신 (Compute Engine VM 또는 GKE 노드)의 이그레스 대역폭은 머신의 모든 네트워크 작업에서 공유됩니다. 클라이언트 머신 또는 포드가 동시에 대용량 패키지를 다운로드하거나, 대규모 로깅 스윕을 실행하거나, 다른 클러스터 노드와 활발하게 통신하는 경우 스토리지 성능은 남은 네트워크 대역폭으로 제한됩니다.