이 페이지에서는 Google Cloud NetApp Volumes의 전자 설계 자동화 (EDA) 워크로드에 대한 아키텍처 패턴을 설명합니다.
NetApp Volumes는 EDA 워크로드를 지원하기 위해 확장성이 뛰어난 NFS 공유 스토리지를 제공합니다. 이러한 워크로드는 수백만 개의 작은 파일로 구성된 페타바이트 규모의 데이터 세트를 처리하고, 메타데이터 집약적인 디렉터리 작업을 실행하며, 수천 개의 컴퓨팅 코어에서 버스트 병렬 I/O를 실행합니다. NetApp Volumes는 프로젝트 크기 볼륨에서 대용량 볼륨으로 확장하여 설계 라이브러리, 툴체인, 스크래치 데이터에 액세스할 수 있도록 지원하며, 하이브리드 및 팬아웃 설계를 위한 FlexCache 옵션을 제공합니다. 다음 패턴은 일반적인 EDA 배포 모델을 이러한 기능에 매핑합니다.
eda-all-on-cloud 및
eda-hybrid-cloud와 같은 GitHub 참조 구현은 Cluster Toolkit EDA 예시를 참고하세요.
아키텍처 패턴
다음 표에는 EDA 워크로드의 일반적인 패턴이 요약되어 있습니다. 사용 사례에 가장 적합한 패턴은 기본 데이터가 상주하는 위치와 읽기 성능 및 컴퓨팅을 확장하려는 방식에 따라 다릅니다.
| 패턴 | 사용 사례 | 기본 NetApp Volumes 기능 |
|---|---|---|
| 컴퓨팅 클러스터용 대용량 볼륨 | 설계 데이터 및 툴체인이 Google Cloud 에 상주하며 대규모로 단일 공유 네임스페이스가 필요함 | 대용량 풀 및 볼륨, 멀티 볼륨 레이아웃, 배포 그룹 수명 주기 |
| 클라우드로 버스트 | 기본 데이터 세트가 온프레미스 또는 다른 리전에 상주하며 최대 수요에 클라우드 컴퓨팅이 필요함 | 온프레미스 ONTAP 출처의 FlexCache, 사전 채우기, 기존 볼륨 |
| 팬아웃 캐시를 통한 성능 확장 | 읽기 중심 단계에는 단일 내보내기가 제공할 수 있는 것보다 더 많은 집계 처리량 또는 지역성이 필요함 | 대용량 볼륨당 여러 FlexCache 볼륨 또는 여러 스토리지 엔드포인트 |
컴퓨팅 클러스터의 파일 스토리지로 대용량 볼륨 사용
컴퓨팅 및 영구 데이터가 모두 Google Cloud(예: 그린필드 EDA 팜, 이전된 설계 센터, 데이터 세트를 소유하는 전용 클라우드 버스트 파티션)에서 실행되는 경우 이 패턴을 사용합니다.
대용량 볼륨으로 해결되는 문제
대용량 볼륨은 대규모 EDA 워크로드의 고용량, 성능, 동시 로드 처리량 요구사항을 해결합니다. 이 구성은 다음과 같은 문제를 해결합니다.
용량 제약조건: 라이브러리, IP 블록, 회귀 스크래치 데이터와 같은 대규모 작업 세트를 수용합니다.
높은 메타데이터 및 I/O 부하: 집약적인 메타데이터 경로 (
readdir및stat작업 포함), 작은 임의 I/O, 높은 순차 대역폭을 처리합니다.
권장 레이아웃
모든 데이터를 단일 대용량 볼륨에 배치하는 대신 수명 주기 및 액세스 패턴에 따라 여러 볼륨에 데이터를 분할합니다.
다음 표에서는 데이터를 분할하기 위한 권장 레이아웃을 설명합니다.
| 볼륨 역할 | 일반적인 데이터 유형 | 액세스 패턴 및 수명 주기 |
|---|---|---|
| 도구 | 공급업체 바이너리 및 라이선스가 부여된 EDA 설치 | 대부분 읽기, 장기 보관, 안정적인 내보내기 |
| 라이브러리 | PDK, 표준 셀, 참조 설계 | 대부분 읽기, 대용량 파일 수, 클라이언트의 속성 캐시 조정의 이점 |
| 홈 | 사용자 점파일 및 소규모 프로젝트 상태 | 혼합 읽기/쓰기 및 적당한 메타데이터 속도 |
| 스크래치 | 실행 디렉터리 및 중간 결과 | 높은 변동, 최대 용량, 가장 높은 IOPS 수요 |
Cluster Toolkit 청사진 eda-all-on-cloud는 NFS를 통해 NetApp Volumes를 마운트하는 Slurm 관리 Compute Engine 파티션으로 이 레이아웃을 프로비저닝합니다.
대용량 볼륨을 사용해야 하는 경우
볼륨이 4.8TiB (Flex Unified) 또는 15TiB (Premium 및 Extreme)보다 큰 경우 대용량 볼륨을 만듭니다. 이러한 볼륨은 매우 큰 용량으로 확장되며 더 높은 처리량 및 IOPS 상한을 제공합니다. 단일 엔드포인트 한도를 초과하는 스크래치 및 라이브러리 볼륨은 이 구성에 적합합니다.
대용량 볼륨의 클라이언트 배포
대용량 볼륨은 여러 스토리지 엔드포인트 (IP 주소)를 동일한 내보내기에 노출합니다. 집계 처리량을 확장하고 단일 IP 주소가 병목 현상이 되지 않도록 여러 엔드포인트에 NFS 클라이언트를 분산합니다. 다음 옵션 중 하나를 사용할 수 있습니다.
라운드 로빈 DNS (대규모로 권장): 여러 IP 주소를 나열하는 Cloud DNS A 레코드를 만듭니다. 각 클라이언트가 마운트 시 한 주소로 확인되도록 FQDN을 사용하여 마운트합니다. DNS 레코드를 변경하는 경우 다시 마운트합니다.
정적 샤딩: 클라이언트를 여러 그룹으로 나누고 각 그룹을 선택한 엔드포인트에 마운트하여 결정적 부하 배치를 수행합니다.
올온클라우드 아키텍처에서는 도구,
라이브러리, 스크래치를 위해 한 Google Cloud 리전에서 별도의
NetApp Volumes 내보내기를 프로비저닝합니다. 도구와 라이브러리는 대부분 읽기 참조 데이터를 보유하고 스크래치는 실행 디렉터리와 체크포인트를 보유하며 대용량 볼륨인 경우가 많습니다. 동일한 VPC의 Slurm 관리 Compute Engine 노드는 NFS를 사용하여 각 내보내기를 마운트합니다. 스토리지는 base 배포 그룹에 배포되고 컴퓨팅은 cluster 그룹에 배포되어 볼륨을 삭제하지 않고 클러스터를 확장하거나 삭제할 수 있습니다.
클라우드로 버스트
권한 있는 설계 데이터가 온프레미스 또는 원격 ONTAP 시스템에 남아 있고 전체 라이브러리를 먼저 복사하지 않고 컴퓨팅 Google Cloud 에서 회귀, 특성 분석 또는 최대 용량 작업을 실행하려는 경우 이 패턴을 사용합니다.
FlexCache로 하이브리드 클라우드 스토리지 문제 해결
FlexCache 볼륨은 다음과 같은 혜택을 제공하여 EDA 환경의 일반적인 하이브리드 클라우드 스토리지 문제를 해결합니다.
LAN과 유사한 액세스 성능: WAN 지연 시간과 대역폭은 클라우드 컴퓨팅 코어가 온프레미스 데이터 세트를 읽을 수 있는 속도를 제한합니다. FlexCache는 작업 세트가 캐시된 후 읽기 중심 단계와 메타데이터 작업을 로컬로 제공하여 이 문제를 해결합니다.
주문형 블록 수준 캐싱: 모든 작업 전에 전체 라이브러리를 클라우드 에 복사하면 시작 지연이 발생하고 스토리지가 중복됩니다. FlexCache는 액세스된 데이터 블록만 캐시하므로 시작 시간이 최소화되고 전반적인 클라우드 스토리지 사용량이 줄어듭니다.
일관된 출처 소스: 데이터의 연결이 끊긴 복사본을 관리하는 대신 클라우드에서 로컬 NFS 내보내기를 사용하고 온프레미스 출처 볼륨에서 단일 일관된 복사본을 유지할 수 있습니다.
FlexCache 동작 및 특성
기존 ONTAP 출처 볼륨을 가리키는 NetApp Volumes에서 FlexCache 볼륨 을 만듭니다. 캐시된 데이터의 읽기는에서 제공됩니다 Google Cloud. 콜드 읽기는 ONTAP 출처 볼륨에서 블록을 한 번 가져온 다음 로컬로 제공합니다. 기본적으로 쓰기 작업은 쓰기 주변을 사용합니다. 캐시는 쓰기 작업을 출처로 전달하고 영향을 받는 캐시된 데이터를 무효화하여 캐시 전반에서 일관성을 유지합니다.
다음은 EDA 환경의 주요 FlexCache 특성입니다.
블록 수준, 가져오기 전용 캐싱: 액세스된 데이터만 캐시 용량을 사용합니다. 스파스 볼륨은 실행당 부분적으로 액세스되는 대규모 라이브러리에 효율적입니다.
일관된 현재 읽기: 캐시 또는 출처에서 읽은 데이터가 일관됩니다. 이 접근 방식은 쓰기 패턴이 FlexCache 가이드와 일치할 때 공유 참조 라이브러리에 적합합니다.
준비 후 LAN과 유사한 읽기 지연 시간: 메타데이터 집약적이고 처리량 집약적인 읽기 단계(예: 라이브러리 순회 및 반복 참조 파일)는 작업 세트가 캐시되면 이점을 얻습니다.
사전 채우기: 첫 번째 액세스 시 콜드 읽기 페널티를 방지하려면 작업을 시작하기 전에 알려진 실행 목록의 디렉터리를 사전 채우기합니다.
하이브리드 참조 청사진
eda-hybrid-cloud
는 도구, 라이브러리, 홈, 스크래치와 같은 기존 볼륨을 사용하여 마운트합니다.
pre-existing-network-storage 볼륨은 표준 NetApp Volumes 내보내기, 대용량 볼륨 또는 FlexCache 볼륨일 수 있습니다. 클러스터 청사진 외부의 스토리지를 프로비저닝하면 컴퓨팅을 삭제할 때 실수로 삭제되는 것을 방지하고 ONTAP에서 관리하는 FlexCache 출처를 지원합니다.
다음 운영 가이드라인을 고려하세요.
전체 출처 볼륨 용량이 아닌 작업 세트의 캐시 볼륨 크기를 조정합니다.
불필요한 캐시 무효화를 방지하려면 출처 볼륨의 액세스 시간 업데이트 (ONTAP의
-atime-update)를 사용 중지하거나 제한합니다. 자세한 내용은 FlexCache 개요를 참고하세요.흐름에 엄격한 교차 캐시 읽기 거부 의미 체계가 필요한 경우에만 전역 파일 잠금 을 사용 설정합니다. 이 접근 방식은 지연 시간을 추가하고 가용성을 출처 링크에 결합합니다.
출처와 Google Cloud간의 네트워크 연결 및 대역폭을 계획합니다. 쓰기 주변을 사용하면 쓰기 중심 단계가 출처 또는 네트워크 링크에 계속 바인딩됩니다.
하이브리드 읽기 버스트 아키텍처에서 권한 있는 도구 및 라이브러리 데이터는 온프레미스 ONTAP 시스템에 상주합니다. NetApp Volumes는 WAN 또는 비공개 링크를 사용하여 이러한 출처를 참조하는 FlexCache 볼륨을 Google Cloud 호스팅합니다. 의 Slurm 노드는 Google Cloud FlexCache 내보내기를 마운트합니다. 데이터가 준비되면 읽기가 캐시에서 제공되고 콜드 읽기는 온프레미스 출처에서 블록을 가져옵니다. 클라우드 컴퓨팅에서 많은 쓰기 트래픽을 수신하는 스크래치 및 체크포인트의 경우 온프레미스 출처가 있는 FlexCache를 통해 지속적인 쓰기 트래픽을 라우팅하는 대신 클러스터와 동일한 리전에 클라우드 네이티브 스크래치 볼륨을 만들어 쓰기를 로컬로 유지합니다.
팬아웃 캐시를 통한 성능 확장
단일 내보내기(대용량 볼륨 포함)가 흐름 단계에 충분한 집계 읽기 처리량 또는 클라이언트 팬아웃을 제공하지 않는 경우 이 패턴을 사용합니다.
팬아웃은 다음 두 가지 방법으로 구현할 수 있습니다.
팬아웃 FlexCache 볼륨
동일한 출처 볼륨으로 지원되는 여러 FlexCache 볼륨을 만들고 서로 다른 캐시에 서로 다른 컴퓨팅 풀 (또는 작업 유형)을 마운트합니다. 각 캐시는 독립적으로 준비되고, 별도의 NetApp Volumes 엔드포인트에서 읽기 I/O를 확장하며, 워크로드 간의 스래싱(예: 라이브러리 전처리 대 장기 회귀)을 격리합니다.
다음 표에서는 단일 및 다중 FlexCache 배포 접근 방식을 비교합니다.
| 접근 방식 | 저울 | 장단점 |
|---|---|---|
| 단일 FlexCache | 단순성, 하나의 마운트 경로 | 하나의 캐시 용량 및 처리량 상한 |
| 여러 FlexCache (팬아웃) | 집계 캐시된 읽기 처리량, 풀당 격리 | 관리할 볼륨이 더 많음, 캐시 간에 작업 세트 분할 |
| 출처만 (캐시 없음) | 단일 사이트에 대한 가장 강력한 쓰기 일관성 | 클라우드 컴퓨팅의 WAN 지연 시간 |
작업 입력을 미리 알고 있는 경우 각 팬아웃 캐시에서 사전 채우기를 사용합니다.
여러 엔드포인트가 있는 대용량 볼륨의 팬아웃
대용량 볼륨 및 FlexCache 볼륨은 볼륨당 여러 IP 주소를 노출합니다. 각 IP를 자체 연결 슬롯 예산이 있는 스토리지 엔드포인트 로 취급합니다.
NFS 클라이언트가 수백 또는 수천 개 있는 경우 다음을 고려하세요.
클라이언트당 RPC 슬롯 테이블 항목 수 줄이기: 예를 들어 NFSv3에서 클라이언트당 8개의 슬롯을 사용하면 엔드포인트당 총 미해결 작업이 권장 한도 (팜 전체에서 엔드포인트당 약 10,000개의 슬롯) 내에 유지됩니다. 자세한 내용은 Linux NFS 동시 실행을 참고하세요.
엔드포인트 간에 마운트 분산: Cloud DNS 라운드 로빈 또는 정적 샤딩을 사용합니다.
FlexCache 팬아웃을 구현하려면 하나의 출처 볼륨 (온프레미스 ONTAP 또는 클라우드 ONTAP 모드 볼륨)을 사용하여 NetApp Volumes에서 여러 FlexCache 볼륨을 지원합니다. Slurm 파티션 또는 작업 클래스와 같은 서로 다른 소비자를 사용하여 각 캐시를 마운트하여 내보내기 전반에서 작업 세트와 읽기 부하를 격리합니다.
멀티 엔드포인트 팬아웃을 구현하려면 여러 IP 주소에서 동일한 NFS 내보내기를 노출하는 하나의 대용량 볼륨을 사용합니다. 각 IP 주소에 고정 클라이언트 그룹을 할당하거나 마운트당 하나의 주소로 확인되는 DNS 이름을 마운트하여 이러한 엔드포인트에 클라이언트를 분산합니다. 각 엔드포인트에는 자체 연결 예산이 있습니다. 클라이언트를 분산하면 팜 전체 I/O가 단일 IP 주소에 집중되는 것을 방지할 수 있습니다.
패턴 결합
프로덕션 EDA 환경의 경우 이러한 아키텍처 패턴을 결합하여 성능을 최적화할 수 있습니다.
올온클라우드: 도구 및 홈에 대용량 스크래치 볼륨과 더 작은 표준 볼륨을 사용합니다.
하이브리드: 작업 출력을 위해 클라우드 프로비저닝된 스크래치 볼륨을 사용하여 라이브러리 및 도구에 FlexCache를 사용합니다.
팬아웃: 사이트 또는 스케줄러 대기열당 FlexCache와 클라우드 네이티브 대용량 스크래치 볼륨의 멀티 엔드포인트 DNS를 사용합니다.
각 계층의 용량 및 성능 요구사항에 맞게 볼륨 서비스 수준 및 풀 유형 (Flex Unified 일반 대 대용량)을 일치시킵니다. 자세한 내용은 서비스 수준을 참고하세요.