이 페이지에서는 최상의 성능을 얻기 위해 Google Cloud Managed Lustre 환경을 구성하는 방법을 안내합니다.
성능 사양
다음 성능 수치는 대략적인 최대값입니다.
IOPS
최대 IOPS는 프로비저닝된 인스턴스 용량의 TiB당 선형으로 확장됩니다.
| 처리량 등급 | 읽기 IOPS (TiB당) | 쓰기 IOPS (TiB당) |
|---|---|---|
125 MBps per TiB |
725 | 700 |
250 MBps per TiB |
1,450 | 1,400 |
500 MBps per TiB |
2,900 | 2,800 |
1000 MBps per TiB |
5,800 | 5,600 |
메타데이터 작업
최대 메타데이터 작업은 프로비저닝된 처리량의 72GBps당 단계적으로 증가합니다.
| 파일 통계 | 파일 생성 | 파일 삭제 | |
|---|---|---|---|
| 72GBps당 | 초당 410,000개 | 초당 115,000개 | 초당 95,000개 |
용량 증가 후 성능
기존 인스턴스의 스토리지 용량을 늘리면 최대 처리량과 IOPS가 증가하고 메타데이터 성능도 증가할 수 있습니다.
새 데이터가 추가 스토리지에 작성되고 재배포됨에 따라 읽기 처리량 성능이 점진적으로 개선됩니다. 쓰기 처리량 성능은 즉시 증가합니다.
VPC 네트워크 최대 전송 단위 (MTU)
VPC 네트워크를 만들 때 mtu
(최대 전송 단위 또는 이 네트워크에서 전송할 수 있는 최대 IP 패킷 크기) 값을 허용되는 최대 값인 8, 896으로 설정하면 기본값인 1, 460바이트에 비해 성능이 최대 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에 균형 조정되는지 확인합니다.
워크로드가 예약된 노드를 식별합니다.
kubectl get pod POD_NAME -o widePOD_NAME을 포드 이름으로 바꿉니다. 명령어 출력에서
NODE열의 이름을 기록해 둡니다.해당 노드에서 네트워크 디버거를 실행합니다.
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을 이전 단계의 노드 이름으로 바꿉니다.
출력에서
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 GByteCtrl+C 를 눌러 디버거를 종료합니다.
단일 클라이언트 성능 측정
단일 Compute Engine 클라이언트에서 읽기 및 쓰기 성능을 테스트하려면
fio (가변형 I/O 테스터) 명령줄 도구를 사용하세요.
fio를 설치합니다.
Rocky 8
sudo dnf install fio -yUbuntu 20.04 및 22.04
sudo apt update sudo install fio다음 명령어를 실행합니다.
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를 예상할 수 있습니다.