이 문서에서는 고성능 컴퓨팅(HPC) 워크로드를 위한 Lustre 파일 시스템을 설계하고 크기를 조정하는 데 도움이 되는 아키텍처 안내를 제공합니다. 또한 DDN EXAScaler를 사용하여 Google Cloud에 Lustre 파일 시스템을 배포하는 프로세스에 대한 개요를 제공합니다.
Lustre는 긴밀하게 결합된 HPC 워크로드에 대해 처리량이 높고 지연 시간이 짧은 스토리지를 제공하는 오픈소스 병렬 파일 시스템입니다. Lustre 파일 시스템을 확장하여 수만 개의 HPC 클라이언트와 페타바이트 규모의 스토리지를 지원할 수 있습니다. EXAScaler Cloud는 Lustre의 엔터프라이즈 버전이며, Google 파트너인 DDN에서 제공합니다. EXAScaler Cloud를 하이브리드 클라우드 아키텍처로 배포하여 온프레미스 HPC 용량을 보강할 수 있습니다. EXAScaler Cloud는 온프레미스 EXAScaler 배포에서 장기 애셋을 저장하기 위한 저장소로도 사용될 수 있습니다.
이 문서의 안내는 클라우드에서 HPC 워크로드의 스토리지를 설계, 프로비저닝, 관리하는 엔터프라이즈 아키텍트 및 기술 실무자를 대상으로 합니다. 이 문서에서는 독자가 병렬 파일 시스템에 대한 개념적 지식이 있다고 가정합니다. Lustre와 같은 병렬 파일 시스템이 이상적인 HPC 사용 사례도 이해해야 합니다. 자세한 내용은 HPC 워크로드 병렬 파일 시스템을 참조하세요.
Lustre 파일 시스템 개요
다음 다이어그램은 Lustre 파일 시스템의 아키텍처를 보여줍니다.
다이어그램과 같이 아키텍처에는 다음 구성요소가 포함되어 있습니다.
관리 서버(MGS) 및 관리 대상(MGT): MGS는 하나 이상의 Lustre 파일 시스템에 대한 구성 정보를 저장하고 관리합니다. 다이어그램은 단일 Lustre 파일 시스템을 관리하는 MGS를 보여줍니다. MGS는 관리하는 모든 파일 시스템의 다른 Lustre 구성요소에 구성 정보를 제공합니다. MGS는 MGT라고 하는 스토리지 기기에 파일 시스템 구성 로그를 기록합니다.
메타데이터 서버(MDS) 및 메타데이터 대상(MDT): MDS 노드는 Lustre 파일 시스템의 네임스페이스에 대한 클라이언트 액세스를 관리합니다. 이 네임스페이스에는 디렉터리 계층 구조, 파일 생성 시간, 액세스 권한과 같은 파일 시스템의 모든 메타데이터가 포함됩니다. 메타데이터는 MDT라고 하는 스토리지 기기에 저장됩니다. Lustre 파일 시스템에는 하나 이상의 MDS와 관련 MDT가 있습니다. 수천 개의 클라이언트가 수백만 개의 작은 파일을 만들고 액세스하는 경우와 같이 메타데이터 집약적인 워크로드의 성능을 향상시키려면 파일 시스템에 MDS 노드를 더 추가하면 됩니다.
객체 스토리지 서버(OSS) 및 객체 스토리지 대상(OST): OSS 노드는 Lustre 파일 시스템에 저장된 파일 데이터에 대한 클라이언트 액세스를 관리합니다. 각 파일은 하나 이상의 Lustre 객체로 저장됩니다. 객체는 단일 스토리지 기기(OST)에 저장되거나 여러 OSS 노드와 OST 간에 스트라이프됩니다. Lustre 파일 시스템에는 하나 이상의 OSS와 하나의 연결된 OST가 있습니다. OSS 노드 및 OST를 추가하여 스토리지 용량과 파일 시스템의 성능을 확장할 수 있습니다. 파일 시스템의 총 스토리지 용량은 파일 시스템의 모든 OSS 노드에 연결된 OST의 스토리지 용량 합계입니다.
클라이언트: Lustre 클라이언트는 가상 머신(VM)과 같이 마운트 지점을 통해 Lustre 파일 시스템에 액세스하는 컴퓨팅 노드입니다. 마운트 지점은 전체 파일 시스템에 통합 네임스페이스를 제공합니다. Lustre 파일 시스템을 확장하여 10,000개가 넘는 클라이언트의 동시 액세스를 지원할 수 있습니다. Lustre 클라이언트는 Lustre 파일 시스템에 있는 모든 MDS 및 OSS 노드에 동시에 액세스합니다. 이러한 병렬 액세스를 통해 파일 시스템의 성능을 극대화할 수 있습니다. 또한 병렬 액세스를 사용하면 다른 위치보다 훨씬 더 자주 액세스하는 스토리지 위치인 스토리지 핫스팟을 줄일 수 있습니다. 핫스팟은 비동시 파일 시스템에서 일반적이며 클라이언트 간에 성능 불균형을 유발할 수 있습니다.
Lustre 파일 시스템에 액세스하기 위해 클라이언트는 MDS에서 필요한 디렉터리 및 파일 메타데이터를 가져온 후 하나 이상의 OSS 노드와 통신하여 데이터를 읽거나 씁니다. Lustre는 밀접한 POSIX 시맨틱스 규정 준수를 제공하며 모든 클라이언트가 파일 시스템에 대한 전체 및 병렬 액세스를 허용합니다.
Lustre 파일 시스템 및 작동 방식에 대한 자세한 내용은 Lustre 문서를 참조하세요.
Google Cloud의 Lustre 아키텍처
다음 다이어그램은 Google Cloud에 Lustre 파일 시스템을 배포하는 아키텍처를 보여줍니다.
이 다이어그램에 표시된 아키텍처에는 다음 리소스가 포함됩니다. 모든 리소스는 단일 Google Cloud 프로젝트에 배포됩니다. 컴퓨팅 및 스토리지 리소스는 단일 영역 내에서 프로비저닝됩니다.
Compute Engine VM은 MGS, MDS, OSS 노드, Lustre 클라이언트를 호스팅합니다. Google Kubernetes Engine 클러스터에 Lustre 클라이언트를 배포하고 Compute Engine VM에 파일 시스템을 배포할 수도 있습니다.
아키텍처에는 다음과 같은 네트워킹 리소스가 포함됩니다.
- 모든 VM에 사용되는 단일 Virtual Private Cloud(VPC) 서브넷입니다.
- 비공개 VM에서 인터넷으로 전송되는 아웃바운드 트래픽을 위한 Cloud NAT 게이트웨이(선택 사항) 및 선택적 Cloud Router(선택 사항)입니다.
- 토폴로지의 모든 VM에 대한 SSH 인그레스 연결을 허용하는 선택적 방화벽 규칙
- 인터넷에서 MGS의 DDN EXAScaler 웹 콘솔로 HTTP 액세스를 허용하는 선택적 방화벽 규칙
- 모든 VM 간 TCP 연결을 허용하는 방화벽
Persistent Disk는 MGS, MDS, OSS 노드를 위한 스토리지 용량을 제공합니다. 영구 스토리지가 필요하지 않은 경우 VM에 연결된 로컬 솔리드 스테이트 드라이브(SSD) 디스크를 사용하여 스크래치 파일 시스템을 빌드할 수 있습니다.
Google에서 영구 및 스크래치 Lustre 파일 시스템의 성능을 모두 보여주는 IO500 항목을 제출했습니다. IO500 HPC 스토리지 시스템 순위에서 10개 이상의 Tbps, Lustre 기반 스크래치 파일 시스템을 보여주는 Google Cloud 제출에 대해 읽어보세요.
설계 가이드라인
다음 가이드라인을 사용하여 HPC 워크로드의 요구사항을 충족하는 Lustre 파일 시스템을 설계합니다. 이 섹션의 가이드라인은 모든 내용을 포함하지는 않습니다. 또한 HPC 워크로드의 스토리지 요구사항을 평가하고, 사용 가능한 스토리지 옵션을 평가하고, Lustre 파일 시스템의 크기를 조정하는 데 도움이 되는 프레임워크를 제공합니다.
워크로드 요구사항
HPC 워크로드의 스토리지 요구사항을 확인합니다. 요구사항을 최대한 세분화하여 정의하고 향후 요구사항을 고려하세요. 다음 질문을 시작점으로 사용하여 워크로드의 요구사항을 확인하세요.
- 처리량 및 초당 I/O 작업 수(IOPS)에 대한 요구사항은 무엇인가요?
- 스토리지 용량이 얼마나 필요한가요?
- 처리량, IOPS, 스토리지 용량 중 가장 중요한 설계 목표는 무엇인가요?
- 영구 스토리지, 스크래치 스토리지 또는 둘 다 필요한가요?
스토리지 옵션
가장 경제적인 스토리지 옵션을 위해 다음 유형의 영구 디스크 중에서 선택할 수 있습니다.
- 표준 영구 디스크(
pd-standard)는 스토리지 용량이 주요 설계 목표인 경우에 가장 경제적인 옵션입니다. 하드 디스크 드라이브(HDD)를 사용하여 효율적이고 안정적인 블록 스토리지를 제공합니다. - SSD 영구 디스크(
pd-ssd)는 IOPS 극대화가 목표인 경우에 가장 경제적인 옵션입니다. SSD를 사용하여 빠르고 안정적인 블록 스토리지를 제공합니다. - 균형 있는 영구 디스크(
pd-balanced)는 처리량 극대화에 경제적인 옵션입니다. SSD를 사용하여 비용 효율적이고 안정적인 블록 스토리지를 제공합니다.
익스트림 영구 디스크(pd-extreme)는 다른 디스크 유형보다 높은 성능을 제공할 수 있으며 개발자는 필요한 IOPS를 선택할 수 있습니다. 하지만 pd-extreme이 다른 디스크 유형보다 비용이 많이 듭니다.
영구 디스크의 성능 기능에 대한 자세한 내용은 블록 스토리지 성능을 참조하세요.
스크래치 스토리지의 경우 임시 로컬 SSD를 사용할 수 있습니다. 로컬 SSD는 VM을 호스팅하는 서버에 물리적으로 연결됩니다. 따라서 로컬 SSD는 영구 디스크보다 높은 처리량과 낮은 지연 시간을 제공합니다. 하지만 로컬 SSD에 저장된 데이터는 VM이 중지되거나 삭제될 때까지만 유지됩니다.
객체 스토리지 서버
OSS 노드의 인프라를 설계할 때 다음을 수행하는 것이 좋습니다.
스토리지의 경우 스토리지 용량, 처리량, IOPS 요구사항에 따라 적절한 Persistent Disk 유형을 선택합니다.
- 다음 요구사항이 있는 워크로드에
pd-standard를 사용합니다.- 워크로드에 높은 스토리지 용량(예: 10TB 이상)이 필요하거나 높은 읽기 처리량과 높은 스토리지 용량이 모두 필요합니다.
- I/O 지연 시간은 중요하지 않습니다.
- 낮은 쓰기 처리량을 사용할 수 있습니다.
- 다음 요구사항이 있는 워크로드에는
pd-balanced를 사용합니다.- 많은 처리량과 낮은 용량.
- SSD 기반 디스크에서 제공하는 짧은 지연 시간.
- 높은 IOPS가 필요한 워크로드(소규모 I/O 요청 또는 작은 파일)에
pd-ssd를 사용합니다.
- 다음 요구사항이 있는 워크로드에
필요한 IOPS를 달성하기에 충분한 스토리지 용량을 프로비저닝합니다. 각 디스크 유형에서 제공하는 읽기 및 쓰기 IOPS를 고려하세요.
VM의 경우 N2 또는 N2D 머신 계열의 머신 유형을 사용합니다. 이러한 머신 유형은 예측 가능하고 비용 효율적인 성능을 제공합니다.
필요한 Persistent Disk 처리량을 달성하도록 충분한 vCPU를 할당합니다. VM당 최대 Persistent Disk 처리량은 1.2GBps이며 이 처리량은 vCPU 16개로 달성될 수 있습니다. 따라서 vCPU가 16개인 머신 유형으로 시작해야 합니다. 성능을 모니터링하고, IOPS를 확장해야 할 때 더 많은 vCPU를 할당합니다.
메타데이터 서버
MDS 노드는 메타데이터를 제공하는 데 높은 스토리지 용량이 필요하지 않지만 높은 IOPS를 지원하는 스토리지가 필요합니다. MDS 노드의 인프라를 설계할 때 다음을 수행하는 것이 좋습니다.
- 이 유형의 Persistent Disk는 낮은 스토리지 용량에서도 높은 IOPS(1GB당 30IOPS)를 제공하므로 스토리지에
pd-ssd를 사용합니다. - 필요한 IOPS를 달성하기에 충분한 스토리지 용량을 프로비저닝합니다.
- VM의 경우 N2 또는 N2D 머신 계열의 머신 유형을 사용합니다. 이러한 머신 유형은 예측 가능하고 비용 효율적인 성능을 제공합니다.
- 필요한 IOPS를 달성하기에 충분한 vCPU를 할당합니다.
- 메타데이터가 적은 워크로드의 경우 16개의 vCPU를 사용합니다.
- 보통의 메타데이터 워크로드의 경우 32개의 vCPU를 사용합니다.
- 메타데이터 집약적인 워크로드의 경우 64개의 vCPU를 사용합니다. 성능을 모니터링하고, 필요한 경우 더 많은 vCPU를 할당합니다.
관리 서버
MGS에는 최소 컴퓨팅 리소스가 필요하며, 이는 스토리지 집약적인 서비스가 아닙니다.
VM은 소규모 머신 유형(예: n2-standard-2), 스토리지는 128GB pd-ssd 디스크로 시작하고 성능을 모니터링합니다.
응답이 느리면 vCPU를 더 많이 할당하고 디스크 크기를 늘립니다.
가용성 및 내구성
영구 스토리지가 필요한 경우 pd-standard 및 pd-balanced Persistent Disk 유형은 영역 내에서 내구성과 가용성이 높은 스토리지를 제공합니다. 영역 간 또는 리전 간 지속성의 경우 Google Cloud CLI 또는 Storage Transfer Service를 사용하여 데이터를 저비용 Cloud Storage로 복사할 수 있습니다.
Cloud Storage에 데이터를 저장하는 비용을 줄이기 위해 자주 액세스하지 않는 데이터를 Nearline Storage 또는 Coldline Storage 클래스에 저장할 수 있습니다.
스크래치 배포에 임시 스토리지만 필요한 경우에는 로컬 SSD를 OSS 및 MDS 노드의 데이터 디스크로 사용합니다. 이 설계는 최소한의 OSS VM 수로 높은 성능을 제공합니다. 이 설계는 다른 옵션과 비교 시 최적의 비용 대비 성능을 달성하는 데도 도움이 됩니다.
OSS VM 크기 조정 예시
Lustre 파일 시스템의 크기를 조절하고 프로비저닝하기 위한 권장 전략은 전체 처리량 요구사항을 충족하도록 충분한 OSS VM을 프로비저닝하는 것입니다. 그런 다음 필요한 스토리지 용량에 도달할 때까지 OST 디스크의 스토리지 용량을 늘립니다. 이 섹션에 사용된 예시 워크로드는 다음 단계를 사용하여 이 전략을 구현하는 방법을 보여줍니다.
- 워크로드 요구사항을 확인합니다.
- Persistent Disk 유형을 선택합니다.
- OSS VM 수를 계산합니다.
- VM당 디스크 크기를 계산합니다.
- VM당 vCPU 수를 결정합니다.
워크로드 요구사항 확인
이 예시에서 워크로드에는 30GBps의 읽기 처리량으로 80TB의 영구 스토리지 용량이 필요합니다.
Persistent Disk 유형 선택
스토리지 옵션 섹션에서 설명한 것처럼 스토리지 용량이 주요 설계 목표인 경우 pd-standard가 가장 비용 효율적인 옵션이며, 처리량을 극대화하는 데는 pd-balanced가 가장 비용 효율적인 옵션입니다. 최대 처리량은 디스크 유형마다 다르며 처리량은 디스크 크기에 따라 확장됩니다.
이 워크로드에 사용할 수 있는 각 Persistent Disk 유형에 대해 읽기 처리량을 30GBps로 확장하는 데 필요한 스토리지 용량을 계산합니다.
| 디스크 유형 | TB당 읽기 처리량 | 대상 처리량을 달성하는 데 필요한 스토리지 용량 |
|---|---|---|
pd-standard |
0.12GBps | 30을 0.12로 나눈 값 = 250TB |
pd-balanced |
0.28GBps | 30을 0.28로 나눈 값 = 107TB |
pd-standard를 사용하여 30Gbps의 대상 읽기 처리량을 달성하려면 250TB의 스토리지 용량을 프로비저닝해야 합니다. 이 용량은 필요한 용량 80TB의 3배를 초과합니다. 따라서 이 예시에서 워크로드의 경우 pd-balanced는 성능 요구사항을 충족하는 비용 효율적인 스토리지를 제공합니다.
OSS VM 수 계산
Compute Engine VM당 최대 읽기 처리량은 1.2GBps입니다. 30GBps의 대상 읽기 처리량을 달성하려면 다음과 같이 대상 읽기 처리량을 VM당 최대 처리량으로 나눕니다.
30 GBps / 1.2 GBps = 25
대상 읽기 처리량을 달성하려면 25개의 OSS VM이 필요합니다.
VM당 디스크 크기 계산
VM당 디스크 크기를 계산하려면 대상 처리량(30GBps)을 달성하는 데 필요한 용량(107TB)을 다음과 같이 VM 수로 나눕니다.
107 TB / 25 VMs = 4.3
VM당 4.3TB의 pd-balanced 용량이 필요합니다.
VM당 vCPU 수 결정
VM의 읽기 처리량은 VM에 할당된 vCPU 수에 따라 확장됩니다. vCPU 16개 이상에 대한 최대 읽기 처리량은 1.2Gbps입니다. vCPU 16개 이상이 있는 머신 유형이 필요합니다. 따라서 N2 또는 N2D 머신 계열에서 머신 유형을 선택합니다(예: n2-standard-32).
구성 요약
예시 워크로드의 요구사항은 다음과 같습니다.
- 80TB 영구 스토리지 용량
- 30Gbps 읽기 처리량
이 워크로드의 요구사항을 충족하려면 다음 컴퓨팅 및 스토리지 리소스가 필요합니다.
- OSS VM 수: 25
- VM 머신 계열: N2 또는 N2D
- VM당 vCPU 수: 16개 이상
- Persistent Disk 유형:
pd-balanced - VM당 디스크 크기: 4.3TB
스크래치 파일 시스템 구성 예시
다음 구성은 Lustre를 사용하고 Google Cloud에 배포되는 대규모 스크래치 파일 시스템의 성능을 보여주는 IO500에 Google Cloud 제출을 기반으로 합니다.
| 구성 매개변수 | MDS | OSS | 클라이언트 |
|---|---|---|---|
| VM 수 | 50 | 200 | 1,000 |
| 머신 유형 | n2-standard-80 |
n2-standard-64 |
c2-standard-16 |
| VM당 vCPU 수 | vCPU 80개 | vCPU 64개 | vCPU 16개 |
| VM당 RAM | 320GB | 256GB | 64GB |
| OS | CentOS 8 | CentOS 8 | CentOS 8 |
| 네트워크 대역폭 | 100Gbps | 75Gbps | 32Gbps |
| 로컬 SSD 스토리지 | 9TB NVMe (디스크 24개) |
9TB NVMe (디스크 24개) |
없음 |
앞의 구성은 다음과 같은 성능을 제공했습니다.
| 성능 통계 | 결과 |
|---|---|
| 쓰기 처리량 | 700GBps(5.6Tbps) |
| 읽기 처리량 | 1,270GBps(10.16Tbps) |
파일 stat() 작업 |
초당 190만 |
| 작은 파일 읽기(3,901바이트) | 초당 150만 |
배포 옵션
이 섹션에서는 Google Cloud에서 EXAScaler Cloud 파일 시스템을 배포하는 데 사용할 수 있는 방법을 간략하게 설명합니다. 이 섹션에서는 클라이언트 VM을 배포할 때 수행해야 할 단계도 설명합니다.
EXAScaler 클라우드 파일 시스템 배포
다음 방법 중에서 선택하여 EXAScaler Cloud 파일 시스템을 Google Cloud에 배포할 수 있습니다.
DDN에서 제공하는 Google Cloud Marketplace 솔루션을 사용하여 배포합니다.
Cloud HPC Toolkit을 사용하여 배포합니다. 툴킷에는 DDN에서 제공하는 Terraform 모듈을 사용하여 높은 I/O 파일 시스템을 배포하는 청사진이 포함되어 있습니다.
두 가지 방법 중 하나를 사용하여 파일 시스템을 배포할 때 맞춤설정할 수 있습니다. 예를 들어 OSS VM 수, VM 머신 유형, Persistent Disk 유형, 스토리지 용량을 지정할 수 있습니다.
방법을 선택할 때는 다음과 같은 차이점을 고려하세요.
배포 후 수정: Cloud HPC Toolkit을 사용하면 배포 후 파일 시스템을 효율적으로 수정할 수 있습니다. 예를 들어 스토리지 용량을 추가하려면 Cloud HPC Toolkit 청사진을 업데이트하고 생성된 Terraform 구성을 다시 적용하여 OSS 노드 수를 늘릴 수 있습니다. 청사진에서 지정할 수 있는 매개변수 목록은 Terraform 모듈의 README의 입력 섹션을 참조하세요. Cloud Marketplace 솔루션을 사용하여 배포된 파일 시스템을 수정하려면 Google Cloud 콘솔, gcloud CLI 또는 API를 사용하여 각 컴퓨팅 및 스토리지 리소스를 개별적으로 변경해야 합니다.
지원: Cloud Marketplace 솔루션은 VPC 서비스 제어에서 지원되지 않는 Deployment Manager를 사용합니다. 이 제한사항에 대한 자세한 내용은 VPC 서비스 제어 지원 제품 및 제한을 참조하세요.
클라이언트 배포
EXAScaler Cloud 파일 시스템 배포 섹션에 설명된 방법 중 하나를 사용하여 클라이언트 VM을 배포할 수 있습니다. 하지만 클라이언트 VM을 파일 시스템과 별도로 프로비저닝하고 관리하는 것이 좋습니다. 클라이언트를 배포할 때 권장되는 방법은 HPC 워크로드에 최적화된 Google 제공 HPC VM 이미지를 사용하는 것입니다.
다음은 HPC VM 이미지를 사용하여 Lustre 클라이언트를 배포하는 프로세스를 간략하게 보여줍니다.
- HPC VM 이미지를 사용하여 VM을 만듭니다.
- VM에 Lustre 클라이언트 패키지를 설치합니다.
- 필요에 따라 VM을 맞춤설정합니다.
- VM에서 커스텀 이미지를 만듭니다.
- 생성된 커스텀 이미지를 사용하여 Lustre 클라이언트 VM을 프로비저닝합니다. 클라이언트 VM의 프로비저닝 및 관리를 자동화하려면 Compute Engine 관리형 인스턴스 그룹 또는 Slurm 워크로드 관리자와 같은 타사 도구를 사용합니다.
- 클라이언트 VM에 Lustre 파일 시스템을 마운트합니다.
데이터 전송 옵션
Google Cloud에 Lustre 파일 시스템을 배포한 후에는 데이터를 파일 시스템으로 이동해야 합니다. 다음 표에서는 데이터를 Lustre 파일 시스템으로 이동하는 데 사용할 수 있는 방법을 보여줍니다. 이전할 데이터 볼륨과 소스 데이터(온프레미스 또는 Cloud Storage)의 위치에 해당하는 방법을 선택하세요.
| 데이터 소스 | 데이터 크기 | 권장 데이터 전송 방법 |
|---|---|---|
| 온프레미스 | 작음(예: 1TB 미만) | gsutil 도구를 사용하여 Cloud Storage의 데이터를 스테이징합니다. 그런 다음 Storage Transfer Service 또는 gcloud CLI를 사용하여 Lustre 파일 시스템에 데이터를 다운로드합니다. |
| 온프레미스 | 크게 | Storage Transfer Service를 사용하여 데이터를 Lustre 파일 시스템으로 이동합니다. POSIX 파일 시스템 간 데이터 전송의 안내를 따릅니다.
이 방법에는 중개 Cloud Storage 버킷 사용이 포함됩니다. 전송 작업이 완료되면 Storage Transfer Service가 중개 버킷의 데이터를 삭제합니다. |
| Cloud Storage | 크거나 작음 | Storage Transfer Service 또는 gcloud CLI를 사용하여 데이터를 Cloud Storage에서 Lustre 파일 시스템으로 다운로드합니다. |
다음 단계
- Lustre에 대해 자세히 알아보세요.
- DDN EXAScaler Cloud 및 DDN과 Google의 파트너십에 대해 자세히 알아보세요.
- IO500 HPC 스토리지 시스템 순위에서 10개 이상의 Tbps, Lustre 기반 스크래치 파일 시스템을 보여주는 Google Cloud 제출에 대해 읽어보세요.
- 이 문서의 EXAScaler Cloud 파일 시스템 배포 섹션에 설명된 대로 Google Cloud에 DDN EXAScaler를 배포하세요.
참여자
저자: Kumar Dhanagopal | 크로스 프로덕트 솔루션 개발자
기타 참여자: