WEKA Architectural Whitepaper

WekaFS 장점

• 모든 IO 프로파일에서 최고의 성능 – 다양한 크기의  파일워크로드에 이상적
• 용량 확장 – 단일 네임스페이스에서 최소 15TB ~ 수백 petabyte까지 확장 가능
• 강력한 보안- 암호화 및 인증을 통해 위협 또는 불량 행위자로부터 데이터를 안전하게 보호
• 하이브리드 클라우드- 모든 주요 클라우드 제공업체로 버스트하여 컴퓨팅 리소스를 민첩하게 조정하거나 클라우드에서 네이티브로 실행
• 백업- 백업을 프라이빗 또는 퍼블릭 클라우드로 바로 푸시하여 장기 보존
• 최고의 경제성 – 플래시와 디스크를 결합하여 규모에 따른 최적의 비용

파일시스템 설계

WekaFS는 처음부터 기존 스케일아웃 NAS 솔루션에 내재된 다양한 문제를 해결하도록 설계되었습니다. 주요 설계 고려 사항 중 하나는 조직 내 다양한 사용자 그룹 또는 멀티테넌트 환경의 요구 사항을 대규모로 처리할 수 있는 소프트웨어 플랫폼을 구축하는 것이었습니다. 가장 널리 사용되는 스케일아웃 NAS 파일시스템은 단일 파일시스템과 단일 네임스페이스의 구조를 지원하며, 디렉토리와 할당량 시스템을 활용하여 리소스를 할당하고 권한을 관리합니다. 이 솔루션은 소규모에서는 효과적이지만 사용자 수 또는 디렉터리 수가 늘어날 경우 관리가 복잡해 집니다. 사용자 그룹을 완전히 격리하려면 새로운 파일시스템과 네임스페이스를 생성해야 하며, 이로 인해 관리해야 할 분산된 물리적 저장 공간이 생깁니다. 또한 디렉터리 확장 문제가 발생하고 일반적으로 성능을 유지하기 위해 여러 디렉터리를 만들어야 하므로 복잡성이 더 커집니다.

따라서 WekaFS는 동일한 물리적 리소스를 공유하는 글로벌 네임스페이스 내의 여러 파일시스템 개념을 수용한다는 점에서 다른 스케일아웃 NAS 솔루션과 차별화됩니다. 각 파일시스템에는 고유한 ‘페르소나’가 있으며, 자체 스냅샷 정책, 오브젝트 스토어 티어링, 조직, 역할 기반 접근 제어(RBAC), 할당량 등을 제공하도록 구성할 수 있습니다. WEKA 파일시스템은 논리적 구조로 되어 있으며 다른 솔루션과 달리 파일시스템 용량을 실시간으로 변경할 수 있습니다. 마운트된 클라이언트는 I/O를 일시 중지할 필요 없이 파일시스템 용량의 변화를 바로 확인할 수 있습니다. 앞서 언급했듯이 각 파일시스템은 오브젝트 스토어로 티어링할 수 있으며, 티어링된 파일시스템인 경우 핫(NVMe) 티어와 오브젝트(HDD) 티어의 비율도 실시간으로 변경할 수 있습니다. 파일시스템은 자체 관리자가 관리하는 여러 조직으로 분할할 수 있습니다.

단일 파일시스템으로 수십억 개의 디렉토리와 수조 개의 파일을 지원할 수 있고 NAS 시스템보다 오브젝트 스토어에 더 가까운 확장성 모델을 제공하며, 성능 손실 없이 디렉토리를 확장할 수 있습니다. 현재 WekaFS는 단일 클러스터에서 최대 1024개의 파일시스템과 최대 24,000개의 스냅샷을 지원합니다.

WekaFS의 한도

• 최대 6.4조 개의 파일 또는 디렉터리
• 글로벌 네임스페이스에서 최대 14 Exabyte 관리 용량
• 디렉토리당 최대 64억 개의 파일
• 단일 파일당 최대 4 Petabyte

지원 프로토콜

적절한 자격 증명과 권한이 있는 클라이언트는 다음 프로토콜 중 하나를 사용하여 데이터를 생성하거나, 수정하고 읽을 수 있습니다.

• POSIX
• NVIDIA^® GPUDirect^® Storage (GDS)⁵
• NFS(Network File System) v3 및 v4.1
• SMB(Server Message Block) v2 및 v3
• S3(Simple Storage Service)

참고: WekaFS는 로컬 마운트처럼 보이기 때문에 대부분의 비전통적 어플리케이션 및 데이터 시스템은 WekaFS가 제공하는 POSIX 기능을 활용할 수 있습니다. 일례로, 하둡 분산 파일 시스템(HDFS)을 들 수 있는데, Weka의 POSIX 커넥터는 하둡(Hadoop) 노드에 직접 마운트하여 매우 높은 성능을 제공합니다.

한 프로토콜에서 파일시스템으로 기록된 데이터는 다른 프로토콜을 통해 읽을 수 있으므로 어플리케이션 간에 데이터를 완전히 공유할 수 있습니다.

WEKA 스토리지 서버

WEKA 스토리지 서버는 적절한 메모리, CPU 프로세서, 네트워킹 및 NVMe SSD가 장착된 표준 AMD EPYC™ 또는 Intel Xeon™ Scalable Processor 기반 하드웨어에 WekaFS를 설치하여 생성됩니다. 두 대의 서버에 장애가 발생해도 견딜 수 있는 클러스터를 생성하려면 6대의 스토리지 서버 구성이 필요합니다. WEKA는 어플라이언스와 유사한 경험을 제공하기 위해 주요 하드웨어 공급업체와 협력하여 소프트웨어 라이선스가 포함된 완전한 스토리지 시스템을 주문할 수 있는 단일 부품 번호를 만들었습니다. Cisco, Dell, HPE, Hitachi Vantara, Lenovo, Penguin, Supermicro, AWS의 특정 구성에 대한 자세한 내용은 해당 공급업체의 웹사이트에서 확인할 수 있습니다.

기타 모든 플랫폼의 경우, 각 호스트는 아래 표 1, 표 2의 최소 사양을 준수해야 합니다.

*WekaFS는 2.2GHz 및 12코어의 최소 1개 이상의 프로세서를 갖춘 x86-64 아키텍처가 필요합니다.

참고: 이 백서 후반부에 언급된 성능을 달성하려면 100Gb 이상의 NIC가 필요합니다.

하이브리드 스토리지를 위한 통합 플래시 및 디스크 계층

WekaFS 스토리지 설계는 두 개의 별도 계층으로 이루어져 있습니다. NVMe SSD 기반의 플래시 계층은 어플리케이션에 고성능 파일 서비스를 제공하고, 선택 사항인 S3 호환 오브젝트 스토리지 계층은 장기 데이터 레이크를 관리합니다(그림 3에 설명). 이 두 계층은 물리적으로는 분리되어 있지만 논리적으로는 어플리케이션에 하나의 확장된 네임스페이스로 작동합니다. WekaFS는 NVMe 플래시 계층에서 오브젝트 스토리지로 네임스페이스를 확장하여 엑사바이트 규모의 단일 글로벌 네임스페이스를 제공합니다. 오브젝트 스토어는 S3-API 호환 공급업체의 제품을 선택하여 온프레미스 또는 퍼블릭 클라우드 환경에서 사용할 수 있습니다. WekaFS는 S3 버킷만 필요로 하기 때문에 기존 오브젝트 스토어는 WekaFS와 공유하면서 네임스페이스를 확장할 수 있으며, 동시에 별도의 버킷에서 다른 어플리케이션을 계속 지원할 수 있습니다. 나중에 살펴보겠지만, WekaFS는 클라우드 버스팅, 클라우드 백업, 다른 WekaFS 클러스터로의 재해 복구(DR) 또는 파일시스템 복제를 제공하기 위해 오브젝트 스토어 기능의 컴포넌트를 활용합니다.

네트워킹

WEKA 시스템은 다음과 같은 유형의 네트워킹 기술을 지원합니다.

• 인피니밴드(IB) HDR 및 EDR
• 이더넷 – 최소 10Gbit, 100Gbit 이상 권장

WekaFS는 모두 비슷한 성능을 제공하므로 고객의 사용 가능한 네트워킹 인프라에 따라 둘 중 하나를 선택해야 합니다. 네트워킹의 경우, WEKA 시스템은 표준 커널 기반 TCP/IP 서비스를 사용하지 않으며, 아래와 같은 자체 개발 네트워킹 스택을 사용합니다:

• DPDK를 사용하여 사용자 공간에서 네트워크 장치를 매핑하고, 커널 간 콘텍스트 스위치를 거치거나 데이터를 복사하지 않고 네트워크 장치를 사용합니다. 커널 스택을 우회하므로 네트워킹 작업에 커널 리소스를 사용하지 않아도 되며 여러 호스트에서 실행되도록 확장될 수 있습니다. 이는 백엔드 및 클라이언트 호스트 양쪽에 모두 적용되며, WEKA 시스템이 최대 여러 개의 200Gbit 이더넷 또는 인피니밴드 링크를 완전히 활용할 수 있도록 합니다.
• UDP를 통해 자체 WEKA 프로토콜을 구현하는 경우, 기본 네트워크에는 서브넷 간의 라우팅이나 UDP를 지원하는 기타 네트워킹 인프라가 포함될 수 있습니다. 클라이언트는 스토리지 노드에 도달할 수 있도록 라우팅이 가능한 한 서로 다른 서브넷에 있을 수 있습니다.

DPDK를 사용하면 높은 처리량과 매우 짧은 지연 시간으로 작업을 수행합니다. 커널을 우회하고 NIC에서 직접 패키지를 송수신함으로써 지연 시간이 단축됩니다. 동일한 호스트의 여러 코어가 병렬로 작동하여 일반적인 병목 현상을 없애기 때문에 높은 처리량을 달성할 수 있습니다.

SR-IOV(단일 루트 I/O 가상화) 및 DPDK를 지원하지 않는 레거시 시스템의 경우, WekaFS는 기본적으로 커널 내 처리(in-kernel processing)를 사용하고 UDP를 전송 프로토콜로 사용합니다. 이 작동 모드는 일반적으로 ‘UDP 모드’라고 하며, 일반적으로 Mellanox CX3 NIC 제품군과 같은 구형 하드웨어에서 사용됩니다.

UDP 모드는 구형 플랫폼과 호환될 뿐만 아니라, CPU 리소스를 전용하지 않으며, 대신 다른 어플리케이션에 CPU 리소스를 할당합니다. 이는 추가 CPU 코어가 다른 용도로 필요할 때 유용합니다.

GPU 가속 컴퓨팅에서 흔히 사용되는 RDMA 지원 환경의 경우, WekaFS는 인피니밴드 및 이더넷용 RDMA를 지원하여 WEKA 프론트엔드 프로세스에 코어를 전용하지 않고도 높은 성능을 제공합니다.

어플리케이션 클라이언트는 이더넷 또는 인피니밴드 연결을 통해 WEKA 스토리지 클러스터에 연결됩니다. WEKA 소프트웨어는 10GbE, 25GbE, 40GbE, 50GbE, 100GbE, 200GbE 이더넷 네트워크와 EDR 및 200Gb HDR 인피니밴드 네트워크를 지원합니다. 이 문서에서 기술한 최상의 성능을 얻기 위해서 최소 100Gbit 네트워크 링크를 사용할 것을 권장합니다.

많은 기업 환경에서는 고성능 컴퓨팅 어플리케이션 클라이언트뿐만 아니라 전통적인 엔터프라이즈 어플리케이션 클라이언트를 모두 지원하기 위해 인피니밴드와 이더넷이 혼합된 네트워크 토폴로지(network topology)를 사용합니다. WekaFS는 이러한 혼합 네트워킹 환경에서 인피니밴드 클라이언트와 이더넷 클라이언트가 동일한 클러스터에 액세스할 수 있도록 지원하므로 모든 어플리케이션이 WEKA의 고성능 스토리지를 활용할 수 있습니다.

WekaFS는 VMware의 VMXNET3 네트워킹을 지원합니다. VMware ESX 하이퍼바이저의 게스트 OS 내에 WEKA 클라이언트를 배포할 때, 한 ESX 서버에서 다른 서버로 vMotion이 발생해도 WEKA 클라이언트는 WekaFS 스토리지에 연결된 상태를 유지합니다.

WEKA와 호환 가능한 지원 NIC 목록은 https://docs.weka.io/support/prerequisites-and-compatibility#networking에서 확인할 수 있습니다.

네트워크 고가용성

WekaFS는 네트워크 인터페이스 카드(NIC) 또는 네트워크 스위치에 장애가 발생하는 경우에도 지속적으로 작동할 수 있도록 고가용성(HA) 네트워킹을 지원합니다. 고가용성은 두 인터페이스에서 신뢰성과 부하 분산을 위해 페일오버 및 페일백을 수행하며 이더넷과 인피니밴드에서 모두 작동합니다. 고가용성을 지원하려면 WEKA 시스템은 하나의 컴포넌트가 단일한 장애 지점이 되지 않도록 구성되어야 합니다. 여러 개의 스위치가 필요하며 호스트는 각 스위치에 연결되어 있어야 합니다. 클라이언트의 고가용성은 동일한 클라이언트에 두 개의 네트워크 인터페이스를 구현하여 달성합니다. 또한 WekaFS는 이더넷의 컴퓨팅 클라이언트(모드 1 및 4)에 대한 링크 집계 제어 프로토콜(LACP)을 지원하며, 단일 듀얼 포트 NIC를 사용합니다. 또한 WekaFS는 인피니밴드 네트워크에 장애가 발생할 경우 고가용성을 유지하기 위해 스토리지 클러스터 내에서 인피니밴드를 이더넷으로 페일오버하는 기능을 지원합니다. 이러한 페일오버는 클라이언트가 두 유형의 네트워크 중 하나에만 연결되어 있어야 하는 경우에는 적용되지 않습니다.

WekaFS는 단일 네트워크 인터페이스 카드(NIC)의 대역폭을 쉽게 포화시킬 수 있습니다. 따라서,여러 개의 NIC를 활용하면 처리량을 높일 수 있습니다. 비LACP 방식을 통해 WEKA 소프트웨어는 두 개의 인터페이스를 사용하여 고가용성과 대역폭을 확보할 수 있는 이중화 기능을 설정할 수 있습니다.  

고가용성 네트워킹 사용 시, 스위치 인터커넥트(ISL) 대신에 동일한 스위치를 통해 호스트 간에 데이터를 전송하도록 시스템에 안내할 수 있습니다. 이를 위해 WEKA 시스템은 네트워크 포트 라벨링 기능을 제공하며, 이는 사용이 용이할 뿐만 아니라 네트워크의 전체 트래픽을 줄일 수 있습니다.

참고: PFC(우선 순위 기반 흐름 제어)를 스위치 패브릭에 구성해야 하는 RoCE 구현과 달리, WEKA는 NVMe-over-fabrics 구현을 지원하기 위해 손실 없는 네트워크 설정이 필요하지 않으며, 공용 클라우드 네트워크에서도 이러한 수준의 저지연 성능을 제공할 수 있습니다.

프로토콜

WekaFS는 다양한 프로토콜에서 완전한 멀티 프로토콜 및 데이터 공유 기능을 지원하며 다양한 어플리케이션 유형과 사용자가 단일 데이터 풀을 공유할 수 있습니다. 다른 병렬 파일시스템과 달리 WekaFS는 이 기능을 위한 추가적인 관리 서버 인프라가 필요하지 않습니다. 현재 지원되는 모든 프로토콜은 아래와 같습니다.

• 로컬 파일시스템 지원을 위한 전체 POSIX
• GPU 가속을 위한 NVIDIA GPUDirect Storage(GDS)
• Linux용 NFS
• Windows용 SMB
• 오브젝트 액세스를 위한 S3POSIX

POSIX

WEKA 클라이언트는 어플리케이션 서버에 설치되는 표준 POSIX 호환 파일시스템 드라이버로, WEKA 파일시스템에 파일 액세스를 가능하게 합니다. 다른 파일시스템 드라이버와 마찬가지로 WEKA 클라이언트는 모든 파일시스템 작업을 가로채서(intercept) 실행합니다. 이를 통해 WEKA는 어플리케이션에 로컬 파일시스템 시맨틱과 성능을 제공하는 동시에 중앙에서 관리되고, 공유 가능하며, 견고한 스토리지 플랫폼을 제공할 수 있습니다. WekaFS는 바이트 범위 잠금과 같은 고급 기능을 제공하며, 이후 캐싱 편에서 다룰 Linux 운영 체제 페이지 캐시와 긴밀하게 통합되어 있습니다.

WEKA POSIX 클라이언트는 가장 낮은 지연 시간으로 IOPS, 대역폭 및 메타데이터에 대해 최고 성능을 제공합니다.

NVIDIA GDS
GPUDirect Storage는 RDMA를 활용하여 서버 NIC와 GPU 메모리 간 대역폭을 향상시키고 지연 시간을 줄이기 위해 NVIDIA에서 개발한 프로토콜입니다. WekaFS는 GDS를 완벽하게 지원하며, NVIDIA의 검증을 받았습니다. 참조 아키텍처는 https://www.weka.io/promo/nvidia-ai-reference-architecture/에서 확인할 수 있습니다.

NFS
NFS 프로토콜을 통해서 원격 시스템이 WekaFS 클라이언트 없이도 Linux 클라이언트에서 WEKA 파일시스템에 접근할 수 있습니다. 이러한 방식은 WEKA의 POSIX 클라이언트 성능을 제공하지는 못하지만, WEKA 스토리지 클러스터에서 데이터를 간편하게 배포하고 공유할 수 있습니다. WekaFS는 현재 NFS v3 및 NFS v4.1을 지원합니다.

SMB

MB 프로토콜을 통해 원격 시스템이 Windows 또는 macOS 클라이언트에서 공유 파일 서비스에 연결할 수 있습니다. 이 프로토콜은 확장 가능하고, 견고하며, 분산된 방식으로 SMB를 구현하며 다음과 같은 다양한 SMB 기능을 지원합니다:

• Active Directory를 통한 사용자 인증(네이티브 및 혼합 모드)
• POSIX 매핑(uid, gid, rid)
• UNIX 확장
• SHA 256 서명
• 식별자 공간 확장
• 동적 크레딧 지원
• 연결 끊김 시에도 지속 가능한 파일 열기
• 심볼릭 링크 지원
• 신뢰할 수 있는 도메인
• 암호화
• 게스트 액세스
• 숨겨진 공유
• SMB ACLs
• Windows에서 POSIX ACL로의 변환
• SMB 보안 관련 공유 옵션

참고: WekaFS는 현재 SMB v2.x를 지원합니다.

S3

많은 웹 기반 어플리케이션이 S3 프로토콜을 지원하지만, S3는 성능 대신 확장성을 고려해 설계되었습니다. IoT 데이터 실시간 분석과 같은 어플리케이션은 고성능 S3 액세스의 이점을 누릴 수 있습니다. WEKA는 고성능 파일시스템에 S3 프론트엔드 지원을 구현하여 S3 스토리지 I/O를 가속화합니다. 특히, WekaFS는 S3를 통해 액세스하는 소규모 파일 I/O에 큰 성능 향상을 제공합니다. WekaFS의 S3 API는 다음 호출을 지원합니다.

• 버킷(HEAD/GET/PUT/DEL)
• 버킷 수명주기(GET/PUT/DEL)
• 버킷 정책(GET/PUT/DEL)
• 버킷 태깅(GET/PUT/DEL)
• 오브젝트(GET/PUT/DEL)
• 오브젝트 태깅(GET/PUT/DEL)
• 오브젝트 멀티파트(POST 생성/완료, GET/PUT/DEL, GET 파트)

또한, WEKA S3 구현은 멀티 프로토콜 액세스, TLS를 지원하며 전체 S3 감사 로그와 정책, 버킷당 할당량 및 정보 수명주기 관리를 위한 만료 규칙 등 버킷 수준의 기능을 제공합니다. 자세한 정보는 https://docs.weka.io/additional-protocols/s3를 참조하세요.

관리 GUI

WEKA는 WEKA 파일시스템을 관리할 수 있는 세 가지 빠르고 간편한 방법을 제공합니다. 그래픽 사용자 인터페이스(GUI), 명령줄 인터페이스(CLI), 또는 대표 상태 전송 API(REST) 중 하나를 선택할 수 있습니다. 보고, 시각화 및 전반적인 시스템 관리 기능은 REST API, CLI 또는 직관적인 GUI 기반 관리 콘솔을 통해 접근할 수 있습니다(그림 5 참조).

간단한 포인트 앤 클릭 방식을 통해 사용자는 새로운 스토리지를 신속하게 프로비저닝하고, 글로벌 네임스페이스 내에서 파일시스템을 생성 및 확장하며, 티어링 정책, 데이터 보호, 암호화, 인증, 권한, NFS, SMB 및 S3 구성, 읽기 전용 또는 읽기-쓰기 스냅샷, 스냅샷-투-오브젝트 및 서비스 품질 정책을 설정하고, 전체 시스템 상태를 모니터링할 수 있습니다. 사용자는 상세 이벤트 로그를 통해 시간에 따른 시스템 이벤트 및 상태를 확인하거나, 시계열 그래프 기능을 통해 특정 시점의 이벤트 세부 사항을 자세히 살펴볼 수 있습니다(그림 6).

시스템 이벤트 메뉴에는 WEKA 환경에서 발생한 이벤트 목록이 표시됩니다. 이 창에 표시된 이벤트는 WEKA 지원 클라우드(WEKA Home; https://home.weka.io)에도 전송되어 필요할 때 WEKA 지원팀의 적극적인 지원을 받거나, 조치가 필요할 때 미리 알림을 받을 수 있습니다. WekaFS GUI는 완전히 웹 기반으로 운영되며, 자체적으로 필요한 모든 리소스를 포함하고 있어 소프트웨어 리소스를 물리적으로 설치하거나 유지관리할 필요가 없으며, 항상 최신 관리 콘솔 기능에 액세스할 수 있습니다.

명령줄 인터페이스(CLI)

모든 WEKA 시스템의 기능 및 서비스는 CLI 명령을 통해 실행할 수 있습니다. 대부분의 WEKA 시스템 명령은 시스템 전체에 적용되며 모든 클러스터 노드에서 동일한 결과를 제공합니다. IP 주소 관리와 같은 일부 명령은 특정 노드에서 실행됩니다.

REST API

모든 WekaFS 시스템 기능과 서비스는 RESTful API 아키텍처를 준수하는 웹 서비스 API를 통해 실행할 수 있습니다. CLI와 마찬가지로 대부분의 WekaFS RESTful 명령은 시스템 전체에 적용되며 모든 클러스터 노드에서 동일한 결과를 제공합니다. 일부 명령은 특정 노드에서 실행됩니다. API는 사용 편의를 위해 Swagger 인터페이스를 통해 제공되며, 여러 프로그래밍 언어로 작성된 API 코드의 예제가 제공됩니다. Swagger 인터페이스의 예는 https://api.docs.weka.io에서 확인할 수 있습니다.

적응형 캐시

 파일 크기가 작고 메타데이터 호출이 많은 어플리케이션에서는 로컬 캐시가 매우 유용합니다. 데이터 지연 시간이 짧고, 공유 네트워크와 백엔드 스토리지 자체의 부하를 줄여줍니다. WEKA 파일시스템은 적응형 캐싱이라는 독특한 고급 캐싱 기능을 제공하여 사용자가 Linux 데이터 캐싱(페이지 캐시)과 메타데이터 캐싱(덴트리 캐시)의 성능 이점을 최대한 활용하면서도 공유 스토리지 클러스터 전반에 완전한 일관성을 유지할 수 있게 합니다. 그러나 NFS v3는 일관성을 지원하지 않기 때문에 Linux 캐싱을 사용하면 읽기 캐시의 경우 데이터 불일치, 쓰기 캐시의 경우 데이터 손상이 발생할 수 있습니다. WekaFS는 일반적으로 직접 연결 스토리지(DAS)나 블록 스토리지 위에서 실행되는 파일 서비스에 할당되어 있는 Linux 페이지 캐시를 활용할 수 있게 지원합니다. 이를 통해 공유 네트워크 파일 시스템에서 전체 데이터 일관성을 유지할 수 있습니다. 지능형 적응형 캐싱 기능은 파일의 독점 사용자(로컬 캐시 모드에서 실행 중인 클라이언트)에게 다른 클라이언트가 데이터 세트에 액세스하고 있다는 사실을 사전에 알려줍니다. 이 플래그가 설정되면 클라이언트는 파일이 다른 클라이언트에 의해 수정될 때까지 로컬 캐시 모드에서 계속 실행할 수 있습니다. 그 후, WekaFS는 로컬 캐시를 무효화하여 두 클라이언트가 가장 최근의 데이터 버전만 액세스할 수 있도록 합니다. 이를 통해 필요한 때  로컬 캐시에서 최고의 성능을 보장하며 항상 데이터의 완전한 일관성을 유지할 수 있습니다. 이 기능은 WekaFS가 캐싱을 동적으로 관리하기 때문에 로컬 페이지 캐시를 활용하기 위해 특정 마운트 옵션을 설정할 필요가 없으며, 관리 오류로 인한 데이터 손상의 위험 없이 WEKA 환경의 프로비저닝을 매우 간단하게 관리할 수 있습니다.

WekaFS는 Linux 덴트리 캐시로도 알려진 메타데이터 캐싱에 대해서도 동일한 기능을 제공합니다. 클라이언트는 디렉토리에 대한 로컬 메타데이터 캐시를 활용하여 지연 시간을 크게 줄일 수 있습니다. 그러나 다른 클라이언트가 동일한 디렉토리에 액세스하는 경우, 한 클라이언트에서 디렉토리가 변경되면 해당 디렉토리에 액세스하는 다른 모든 클라이언트의 캐시된 메타데이터가 무효화됩니다. 캐싱 기능에는 확장 속성과 접근 제어 목록(ACL)도 포함됩니다.

일부 공유 파일 스토리지 공급업체는 로컬 캐싱을 허용하지만, WekaFS의 적응형 캐싱 기능은 다른 파일 시스템에서는 제공하지 않습니다. 캐싱은 대개 기본적으로 비활성화되어 있으며 관리자가 마운트 옵션을 변경해야 합니다. 일반적으로 커밋된 쓰기의 데이터 일관성을 보장하기 위해 클라이언트에서 배터리 백업 보호에 의존하는 경우가 많기 때문입니다. WEKA의 캐싱 구현은 쓰기가 확인된 데이터의 보존에 있어서 배터리 백업에 의존하지 않기 때문에 관리자의 개입 없이 바로 작동합니다. 따라서 온프레미스에서 실행되는 동일한 소프트웨어를 소프트웨어 변경 없이 퍼블릭 클라우드에 원활하게 배포할 수 있습니다. 이 기능은 ‘Untar’와 같이 공유 파일 시스템 대비 로컬 프로세스로 실행될 때 훨씬 빠르게 실행되는 사용 사례에 이상적입니다.

글로벌 네임스페이스 및 확장

WekaFS는 시스템 내의 모든 데이터를 글로벌 네임스페이스의 일부로 관리하며, 단일 하이브리드 아키텍처에서 두 개의 영구 스토리지 티어인 활성 데이터용 NVMe SSD와 데이터 레이크용 HDD/하이브리드 플래시 기반 오브젝트 스토리지를 지원합니다. 네임스페이스를 오브젝트 스토어로 확장하는 것을 글로벌 네임스페이스에 선택적으로 추가할 수 있으며, 관리 콘솔에서 몇 번의 클릭만으로 구성할 수 있습니다. 파일은 활성 상태이거나 사전 설정 또는 사용자 정의 정책에 따라 오브젝트 스토리지로 티어링되기 전까지 플래시에서 존재합니다. 파일이 오브젝트 스토어로 티어링되면 새 데이터에 물리적 공간이 필요할 때까지 원본 파일이 플래시 계층에 유지됩니다. 따라서 덮어쓰기 될 때까지 캐시 파일로 작동합니다. 파일 데이터가 오브젝트 스토어 티어로 이동될 때, 파일 메타데이터는 항상 로컬로 플래시 티어에 남아 있으므로, 애플리케이션은 티어링 배치와 관계없이 작성된 위치에서 모든 파일을 사용할 수 있습니다. 이는 오브젝트 스토어 버킷이 공용 클라우드에 있는 경우에 마찬가지입니다. NVMe 플래시 시스템 용량이 소진되고 사용량이 높은 수위에 도달하면 데이터가 오브젝트 티어로 동적으로 푸시되므로 플래시 티어의 용량 부족으로 인한 걱정은 없습니다. 관리자의 개입이 필요하지 않기 때문에 쓰기 집약적인 어플리케이션에 특히 유용합니다. 플래시 티어와 오브젝트 티어는 필요한 사용 용량에 따라 독립적으로 확장할 수 있습니다.

글로벌 네임스페이스는 1024개의 파일시스템으로 세분화할 수 있으며, 파일시스템 용량은 언제든지 더 많은 공간을 할당하여 즉각적으로 확장할 수 있습니다. 따라서, 파일시스템을 마운트 해제하고 다시 마운트할 필요가 없습니다. 네임스페이스를 세분화하여 개별 사용자, 프로젝트, 고객 또는 기타 매개변수에 스토리지 용량을 할당할 수 있으며, 중앙에서 손쉽게 관리할 수 있습니다. 파일시스템 내의 데이터는 다른 모든 파일시스템과 완전히 격리되어 있어 시끄러운 이웃 문제를 방지합니다.  

씬 프로비저닝

WekaFS는 글로벌 네임스페이스 내에서 파일시스템의 씬 프로비저닝을 허용합니다. 클러스터에 호스트가 추가되면 사용 가능한 모든 용량을 풀링하여 씬 프로비저닝된 리소스로 액세스할 수 있습니다. 이 기능은 호스트나 드라이브가 추가될 때 자동으로 용량을 확장할 수 있을 뿐만 아니라 클러스터에서 호스트나 드라이브 제거 시 공간을 관리하는 데에도 중요합니다. 호스트나 드라이브를 제거한 후 남은 가용 용량은 모든 파일시스템의 플래시 티어에 저장된 데이터를 지원하기에 충분해야 합니다. 이 기능을 통해 AWS의 EC2 자동 확장 그룹 및 GCP, OCI, Azure 등의 다른 하이퍼스케일 클라우드의 자동 확장 기능과 원활하게 통합할 수 있습니다.

무중단 업그레이드

WekaFS는 클라이언트에 영향을 주지 않고 업그레이드할 수 있습니다. WEKA는 컨테이너와 컨테이너 내부의 프로세스 세트를 운영체제로 사용하기 때문에 클라이언트를 다시 마운트하지 않고도 롤링 방식으로 컨테이너를 업그레이드할 수 있습니다. 이 기능과 WEKA의 견고한 데이터 보호 스키마가 결합되면 WekaFS를 실시간으로 업그레이드하는 동안 최소한의 I/O 일시 중지만 발생합니다. 따라서 업그레이드 과정에서 클라이언트를 마운트 해제하고 다시 마운트할 필요가 없습니다.

통합 계층형 데이터 관리

WekaFS는 데이터의 온도에 따라 스토리지 유형 간에 데이터를 자동으로 이동하는 정책 기반 자동 데이터 관리 기능을 갖추고 있습니다. WEKA는 NVMe 플래시 스토리지 티어에서 온프레미스 또는 클라우드 기반 오브젝트 스토리지로의 데이터 이동을 지원합니다(그림 7). 데이터 이동은 파일시스템 수준에서 설정되며 이는 NVMe 플래시 티어의 선택적 확장 기능입니다. 예를 들어, 항상 최고의 성능을 보장하기 위해 사용자는 특정 파일시스템을 NVMe SSD에 독점적으로 유지하고, 다른 파일시스템은 오브젝트 스토리지로 데이터를 이동시켜 비용을 절감합니다. 메타데이터는 항상 플래시 티어에 저장되며, 데이터 구조를 포함한 전체 파일시스템의 읽기 전용 또는 읽기-쓰기 스냅샷을 오브젝트 스토리지 티어에 저장하여 플래시 티어의 장애에 대비할 수 있습니다. 어플리케이션 클라이언트는 파일이 어떤 스토리지 티어에 있든지 간에 파일시스템의 모든 파일을 작성된 위치에서 확인할 수 있으므로 비용 최적화된 오브젝트 스토리지 기반 솔루션을 활용하기 위해 어플리케이션을 변경할 필요가 없습니다.

이러한 통합 기능을 활용하면 추가적인 계층적 스토리지 관리(HSM) 또는 데이터 티어링 소프트웨어를 사용할 필요가 없으므로 복잡성과 비용을 줄일 수 있습니다. 통합 데이터 관리 기능으로 클라우드 공급업체의 용량 한도까지 확장 가능한 탄력적인 통합 네임스페이스를 활용할 수 있습니다. 인증된 오브젝트 스토어 목록은 https://docs.weka.io/support/prerequisites-and-compatibility#object-store에서 확인할 수 있습니다.

NVMe 플래시와 오브젝트 스토어 중 어느 쪽에 더 많은 데이터를 저장해야 하는지에 대한 정해진 규칙은 없지만, WEKA고객 설문조사에 따르면 일반적으로 약 20%의 데이터가 플래시에 저장되어 있습니다(그림 7 참조). 경험적으로 볼 때 현재 워크로드를 처리하는데 필요한 일반적인 작업 데이터 세트를 저장할 수 있도록 플래시 티어를 측정하고, 새로운 작업 워크로드를 최대 성능으로 실행하기 위해 사전에  충분한 용량을 확보하는 것이 좋습니다.

WekaFS로의 데이터 마이그레이션

오브젝트 스토리지 티어는 지속적인 데이터 분석과 데이터 인사이트를 위한 대규모 데이터 웨어하우스 또는 데이터 레이크를 구축할 수 있는 이상적인 인프라 옵션입니다. WekaFS는 여러 데이터 레이크를 대규모로 확장 가능한 단일 데이터 웨어하우스로 통합하여 고성능 데이터 액세스 및 데이터 처리 기능을 갖춘 단일한 엑사스케일 네임스페이스를 구축할 수 있습니다.  

수명이 완료된 하드웨어 플랫폼이나 원격 버킷에서 마이그레이션하는 경우 데이터 수집에 의해 파일시스템이 포화되면 시스템에서 정상적인 I/O를 실행하는 다른 어플리케이션의 성능이 저하되므로 이는 관리자에게 문제가 될 수 있습니다. WekaFS는 플래시 티어 용량을 소모하지 않고 수집된 데이터를 오브젝트 스토어로 직접 전달하는 마운트 옵션을 제공합니다. 이 기능을 사용하면 다른 어플리케이션의 정상적인 작동을 유지하면서 WEKA 스토리지 시스템을 ‘지연 이전(lazy migration)’할 수 있습니다.

스냅샷과 클론

WEKA는 일반적인 데이터 보호를 위해 사용자 정의 가능한 스냅샷을 지원하며, 이는 백업뿐만 아니라 클라우드 데이터 마이그레이션 및 클라우드 버스팅에도 사용됩니다. 예를 들어, WekaFS 스냅샷은 플래시 티어의 파일을 로컬로 백업하고 백업 또는 재해 복구를 위해 클라우드 스토리지 티어로 복사본을 만들 수 있습니다. 또한, WEKA 스냅샷은 저렴한 콜드 스토리지(퍼블릭 클라우드 및 온프레미스 오브젝트 스토리지 등)에 저장할 수 있습니다. 특정 시점 스냅샷 외에도 WekaFS는 원본 데이터에 대한 포인터를 사용하여 파일 시스템의 전체 클론(읽기 전용 스냅샷을 쓰기 가능한 스냅샷으로 변환할 수 있는)을 생성할 수 있습니다. WekaFS 스냅샷과 클론은 즉시 생성되며, 첫 번째 인스턴스 이후에는 증분 방식으로 생성되어 보호에 필요한 시간과 스토리지를 크게 절감할 수 있습니다. 또한, 스냅샷 프로세스나 클론에 데이터 쓰기 중에도 시스템 성능에 영향을 주지 않습니다. 스냅샷은 GUI, CLI 또는 REST API 호출을 통해 생성할 수 있습니다. WekaFS는 다음을 지원합니다:

• 읽기 전용 스냅샷
• 읽기/쓰기 스냅샷
• 기본 스냅샷 삭제, 다른 모든 버전 유지
• 모든 스냅샷 삭제, 전후버전 유지
• 읽기 전용을 읽기/쓰기 스냅샷으로 변환
• 스냅 투 오브젝트(다음 섹션 참조)

스냅샷은 /.snapshot 디렉토리를 통해 클라이언트에 노출됩니다. 티어링을 활성화하면 스냅샷 데이터는 활성 파일시스템과 동일한 정책에 따라 오브젝트 티어로 이동합니다.

스냅 투 오브젝트

파일시스템에서 티어링을 활성화하면 WekaFS는 스냅 투 오브젝트라는 독특한 기능을 지원합니다. 이 기능을 사용하면 메타데이터를 포함한 특정 스냅샷의 모든 데이터를 오브젝트 스토어에 커밋할 수 있습니다. 티어링을 활용하는 데이터 수명 주기 관리 프로세스와 달리, 이 기능은 모든 파일과 메타데이터를 포함한 모든 스냅샷의 내용을 오브젝트 스토어로 복사합니다. 첫 번째 스냅 투 오브젝트가 완료된 후 후속 스냅샷이 증분 방식으로 저장되며 변경 사항만 백업이 진행되므로 매우 빠르게 처리됩니다. WekaFS는 원격 백업 기능을 사용해 두 번째 오브젝트 스토어로 스냅샷을 전송하는 기능도 지원합니다. 이 기능은 스냅샷의 증분적 성격을 활용하여 변경 사항만을 대상 오브젝트 스토어로 전송하며, 대상 오브젝트 스토어는 업로드 되는 각 스냅샷의 전체 용량이 아닌 특정 시점의 스냅샷의 증분 용량만 저장하면 됩니다.

스냅 투 오브젝트에는 증분 스냅샷 다운로드 기능도 포함되어 있습니다. 소스 파일시스템의 초기 스냅샷을 오브젝트 스토어에서 다운로드하여 새 파일시스템에 복원하면, 해당 소스 파일시스템의 후속 스냅샷을 대상 파일시스템에 증분식으로 복원할 수 있습니다. 이 기술을 통해 WEKA POSIX 클라이언트를 사용하여 파일이나 디렉토리를 닫았다가 다시 열면 대상 파일시스템의 모든 업데이트를 확인할 수 있고, 다른 프로토콜을 사용하는 경우에는 파일이나 디렉토리를 닫고 클라이언트 캐싱을 무효화하면 업데이트를 확인할 수 있습니다. 클라이언트는 변경 사항을 확인하기 위해 파일시스템을 마운트 해제했다가 다시 마운트할 필요가 없습니다.

스냅 투 오브젝트 기능을 사용하면 오브젝트 스토어에 데이터 스냅샷의 전체 복사본이 저장되므로, 이를 사용하여 원래의 WEKA 클러스터 또는 다른 WEKA 클러스터에 데이터를 복원할 수 있습니다. WekaFS 스냅 투 오브젝트 스냅샷을 마운트하는 보조 클러스터는 기본 시스템과 동일하게 구성할 필요가 없습니다. 실제로 기본 시스템에는 클러스터에 20개의 스토리지 호스트가 있을 수 있지만, 보조 시스템에는 6개, 10개 또는 100개의 스토리지 호스트가 있을 수 있습니다. 클러스터 크기에 관계없이 작동하며, 클라우드 버스팅에 이상적입니다. 따라서, 스냅 투 오브젝트 기능은 다음과 같은 다양한 사용 사례에 유용합니다:

1. 일반적인 사용 사례(온프레미스 및 클라우드)

• 온프레미스 또는 클라우드 기반 오브젝트 스토어에 데이터 백업: 시스템 장애 또는 화재, 지진, 홍수 등 외부 사건으로 인해 WEKA 클러스터의 많은 하드웨어 컴포넌트가 복구할 수 없을 정도로 손상된 경우, 오브젝트 스토어에 저장된 스냅샷을 사용하여 다른 WEKA 클러스터에 동일한 데이터를 재생성하거나 원래 클러스터로 재복원할 수 있습니다.
• 데이터 아카이브: 데이터 스냅샷을 주기적으로 생성한 다음, 스냅샷을 오브젝트 스토어나 클라우드에 업로드하여 데이터의 아카이브 복사본을 만듭니다. 이를 위해 WEKA는 AWS Glacier Instant Retrieval과 같이 “더 저렴하고 심층적인” 오브젝트 스토어 서비스를 지원할 수 있습니다.
• 비동기식 데이터 미러링: WEKA 클러스터와 다른 데이터 센터에 있는 복제된 오브젝트 스토어를 결합하면 두 번째 WEKA 클러스터에 마운트할 수 있는 미러 데이터가 생성됩니다.

2. 클라우드 전용 사용 사례

• 퍼블릭 클라우드 일시 중지 및 재시작: WEKA는 다양한 클라우드 제공업체의 컴퓨팅 인스턴스와 로컬 SSD를  활용하여 클러스터를 생성합니다. 프로젝트별 작업이 버스트되는 경우, 사용자는 비용을 절감하기 위해 클러스터를 종료하거나 절전 모드로 전환할 수 있습니다. 스냅샷을 오브젝트 스토어에 저장했다가 필요할 때 다시 복원할 수 있습니다.
• 단일 가용 영역 장애에 대한 보호: 스냅 투 오브젝트 기능을 활용하여 가용 영역(AZ) 장애를 복구할 수 있습니다. 첫 번째 AZ에 장애가 발생하는 경우, WEKA 스냅샷이 오브젝트 스토어를 통해 두 번째 AZ로 복제된 경우, 두 번째 AZ의 WEKA 클러스터는 몇 분 안에 이를 복원할 수 있습니다.

3. 하이브리드 클라우드 사용 사례

• 클라우드 버스팅: 온프레미스 고객은 단기간에 추가적인 컴퓨팅 성능을 사용하여 클라우드 탄력성의 이점을 누릴 수 있습니다. 클라우드 기반 오브젝트 스토어에 스냅샷을 업로드하여 파일시스템을 클라우드에서 실행할 수 있습니다. 클라우드에서 실행 후 데이터를 삭제하거나 아카이빙하고 컴퓨팅 인스턴스를 종료할 수 있습니다.

데이터 보호

데이터 보호는 스토리지 시스템의 중요한 기능이며, 규모가 커질수록 문제도 많아집니다. 적절한 내부 데이터 보호 스키마가 없는 경우, 디스크 또는 호스트 재구성에 걸리는 시간에 따른 영향을 고려하고 데이터 노출 위험을 최소화하기 위해 파일시스템의 크기를 제한해야 합니다. 널리 사용되는 데이터 보호 방법인 RAID, 내부 복제 및 삭제 코딩은 확장성, 보호 수준, 용량, 성능을 감안한 절충 방안입니다.   

WEKA에서는 모든 데이터와 메타데이터가 스토리지 서버에 고르게 분산되어 있어 데이터 또는 메타데이터 로컬리티의 개념이 없으므로 확장성, 총 성능, 내구성이 향상됩니다. 고속 네트워크의 등장으로 데이터 로컬리티는 데이터 핫스팟과 시스템 확장성 문제를 일으키며 이는 성능 및 신뢰성 문제로 이어집니다. WekaFS는 SSD 레이어에서 데이터 배치를 직접 관리함으로써 사용자가 구성할 수 있는 스트라이프 크기를 기반으로 데이터를 스토리지 클러스터 전체에 데이터를 분산시켜 최적의 배치를 구현합니다. WekaFS는 고급 알고리즘을 사용하여 데이터 레이아웃을 결정하며, 기본 플래시 메모리에서 사용되는 블록 크기와 완벽하게 일치시켜 성능을 개선하고 SSD 서비스 수명을 연장합니다. 스트라이프 크기는 4~16 사이 값으로 설정할 수 있으며 패리티는 +2 또는 +4로 설정할 수 있습니다. 그림 8은 6+2 구성에서 SSD 간 데이터 배치를 보여줍니다. 지원되는 최소 클러스터 크기는 6으로, 4+2 구성에서 재구성 시 2개의 완전한 가상 예비 공간을 확보할 수 있습니다. WEKA 클러스터가 클수록 지원할 수 있는 스트라이프 크기가 커지고 스토리지 효율성과 쓰기 성능이 향상됩니다.

WekaFS 데이터 보호 스키마

WekaFS는 데이터를 항상 안전하고 접근 가능하도록 보호 관리합니다:

• 4+2 ~16+4 까지 데이터 보호 수준 구성 가능
• 분산 데이터 보호 스키마 특허 획득
• 장애 도메인 구성 가능
• 데이터 무결성을 위한 엔드 투 엔드 체크섬(checksum)
• 메타데이터 저널링
• 로컬 스냅샷 및 클론
• 백업과 재해 복구를 위한 스냅샷 투 오브젝트

WEKA는 데이터 보호 수준을 정의하기 위해 장애 도메인을 활용합니다. 장애 도메인은 서버 호스트 수준에서부터  완전히 구성 가능하며, 단일 또는 다중 SSD 수준의 세분화가 가능합니다.데이터 보호 수준은 서버 클러스터의 크기와 규모에 따라 유연하게 설정할 수 있으며, 클러스터가 클수록 SSD 용량의 최적 활용, 성능 및 내구성 향상을 위해 권장되는 데이터 스트라이프 크기도 더 커집니다. 세분화된 보호를 위해 데이터 보호 수준은 클러스터 수준에서 설정되며 패리티는 2 또는 4로 설정할 수 있어 시스템은 데이터 가용성에 영향을 주지 않고 최대 2~4개의 동시 호스트 장애를 견딜 수 있습니다.

WEKA의 데이터 보호 방법은 데이터(N) + 패리티(2~4)의 규칙을 따릅니다. N + 4 데이터 보호 수준은 클라우드 스토리지 관점에서 보면 독특한 방식입니다. 대부분 클라우드 기반 스토리지 서비스는 3중 복제 방식을 사용하여 데이터를 보호합니다. WEKA의 데이터 보호 방식은 최대 2회의 장애까지만 보호하는 3중 복제보다 훨씬 뛰어난 복원성을 제공하며, 고가의 스토리지와 처리량에 영향을 주지 않습니다. 컨버지드(어플리케이션과 스토리지가 동일한 호스트를 공유하는) 클러스터나 전용 어플라이언스 등 대부분의 프로덕션 환경에서는 N + 2 보호 수준이면 충분합니다. 다수의(수백 대) 컨버지드 클러스터 서버가 있는 클러스터의 경우 어플리케이션 장애 또는 잠금으로 인해 서버 가용성에 영향을 줄 수 있으므로 N+4 보호 수준이 권장됩니다.

핵심 데이터 보호 이외에도 중복 전원 공급 장치가 있는 서버, 네트워크 이중화를 위한 다중 NIC 및 스위치 등 가용성 모범 사례를 권장합니다.

가상(핫) 스페어

가상(핫) 스페어란 일종의 예비 용량으로, 장애 도메인에 장애가 발생하면 시스템이 데이터를 완전히 재구성하고 동일한 순 용량이 유지될 수 있도록 합니다. 모든 장애 도메인은 항상 데이터 저장에 참여하며, 가상 스페어 용량은 모든 장애 도메인에 고르게 분산됩니다.

가상 스페어 수가 많을수록 동일한 순 용량을 확보하기 위해 필요한 하드웨어도 많아집니다. 반면, 교체를 위한 IT 유지보수 일정은 더 유연해 집니다. 가상 스페어는 클러스터가 형성될 때 정의되며 언제든지 재구성할 있습니다. 기본 가상 스페어 수는 1개입니다.

데이터 분산

클러스터의 서버 수가 증가함에 따라 내구성을 높이기 위해 특허⁸ 분산 데이터 보호 코딩 체계를 활용합니다. 이 방식은 삭제 코딩의 확장성과 복구 능력을 제공하면서도 성능 저하가 없습니다. 기존 하드웨어 및 소프트웨어 RAID 및 다른 데이터 보호 방법과 달리, WEKA는 시스템 확장 시 클러스터의 모든 서버가 리빌드 프로세스에 참여하기 때문에 복구에 걸리는 시간이 단축되고 복구 능력이 뛰어납니다.

WekaFS는 데이터와 메타데이터를 장애 도메인에 있는 논리적 버킷에 균등하게 분산합니다. 개별 스토리지 서버, 랙 또는 데이터 센터도 장애 도메인이 될 수 있습니다. 클라우드 환경에서 WekaFS는 여러 가용 영역(AZ)에 걸쳐 데이터를 분산할 수 있습니다.

WEKA는 기존의 하드웨어 및 소프트웨어 데이터 보호 방식과는 달리 특정 데이터 스트라이프의 단일 세그먼트만 각 서버(또는 FD) 내에 배치합니다. 따라서 단일 서버 내에서 여러 드라이브에 장애가 발생하는 경우에도 도메인의 단일 장애로 간주됩니다. 데이터 분산 메커니즘은 항상 여러 장애 도메인 전체에 걸쳐 스트라이프를 분산하며, 보호 수준은 FD 수준에서 정의됩니다. WekaFS는 FD 수준에서 장애를 처리하므로 FD 내의 개별 또는 여러 장애는 단일 장애로 취급됩니다. 데이터 스트라이프는 선택한 내구성 수준에 따라 항상 다른 서버 호스트, 랙 또는 AZ에 분산됩니다. WEKA의 내구성은 사용자 설정이 가능합니다. 사용자가 WEKA 클러스터 내에서 허용할 수 있는 장애의 수를 정의함으로써 어플리케이션 워크로드 서비스 수준 요구 사항을 충족할 수 있습니다. 장애가 발생하면 시스템은 정의된 도메인 크기에 관계없이 해당 장애를 단일 장애로 간주합니다. WEKA는 FD 수준에서 스트라이프를 분산하는 것 외에도 성능과 내구성 향상을 위해 무작위 데이터 배치를 보장합니다. 클러스터 크기가 커질수록 하드웨어 장애 발생 확률이 비례해서 증가하지만, WekaFS는 무작위 방식으로 스트라이프를 배포하여 이 문제를 극복합니다. 서버가 많을수록 무작위 스트라이프 조합이 증가하여 이중 장애가 발생할 확률이 낮아집니다. 예시: 스트라이프 크기가 18(16+2)이고 클러스터 크기가 20인 경우 가능한 스트라이프 조합의 수는 190개입니다. 그러나 클러스터 크기가 25로 증가하면 가능한 스트라이프 조합의 수는 480,700개가 됩니다. 가능한 스트라이프 조합의 수는 다음 공식으로 계산하며, 여기서 C는 클러스터 내 서버 수이고 S는 스트라이프 크기입니다: C!/(S!*(C-S)!).

WekaFS 리빌드   

WEKA는 시스템을 가능한 한 빨리 완전히 보호된 상태로 되돌리고 후속 장애를 처리할 준비를 하기 위해 혁신적인 전략을 사용합니다. 이를 통해 데이터 리빌드 프로세스가 지연 되더라도 어플리케이션에 영향을 주지 않습니다.  

WEKA는 파일 수준에서 데이터를 보호하기 때문에 장애가 발생한 서버 또는 SSD에 활성 상태로 저장된 데이터만을 리빌드해야 합니다. 즉, 블록 레이어에서 데이터를 보호하는 기존 RAID 솔루션이나 파일 서버에 비해 리빌드 시간이 단축됩니다. 일반적으로 RAID 컨트롤러 기반 시스템은 영향 받은 저장 장치(SSD/HDD)에서 비어 있는 블록을 포함하여 모든 블록을 재구성하므로 복구 시간 및 노출 시간이 길어집니다. WEKA는 장애가 발생한 특정 파일 데이터만 재구성하면 됩니다. 파일시스템에 오브젝트 티어링 정책이 적용된 경우, 이미 오브젝트 스토어로 티어링된 데이터는 서버 장애의 영향을 받지 않는 추가적인 이점이 있습니다. 또한 캐시된 데이터(오브젝트로 티어링되었지만 무효화될 때까지 플래시 티어에 남아 있는 데이터)는 리빌드할 필요가 없으므로 리빌드 우선순위는 플래시 티어에만 존재하는 데이터로 한정됩니다.

WEKA의 스트라이프는 4K 블록으로 구성됩니다. 스트라이프는 사용 가능한 모든 장애 도메인에 분산됩니다. 동일한 스트라이프에 속하는 두 블록은 동일한 장애 도메인에 기록되지 않습니다. 따라서 장애 도메인 하나를 잃으면 스트라이프에서 하나의 블록만 손실됩니다. 클러스터 내 남은 모든 장애 도메인은 스트라이프 내에 누락된 블록을 리빌드하는데 참여합니다. 여기에는 단일 디스크 장애, 호스트 장애 또는 전체 장애 도메인 장애가 포함됩니다. WEkaFS는 패리티 계산을 사용하여 해당 드라이브 또는 장애 도메인에서 데이터를 재구성하고, 남은 모든 정상 장애 도메인에 데이터를 기록합니다. 클러스터의 크기가 커질수록 리빌드 프로세스에 참여할 수 있는 컴퓨팅 리소스가 더 많아지고, 스트라이프가 더 많은 호스트에 무작위로 분산되기 때문에 재구성 속도가 빨라지고 시스템의 신뢰성이 향상됩니다. 여러 번의 장애가 발생할 경우, 시스템은 가장 취약한 상태의 데이터 스트라이프부터 먼저 리빌드합니다. WEKA는 장애가 발생한 호스트에서 공통적으로 나타나는 데이터 스트라이프를 찾아서 우선적으로 재구성하므로 시스템이 가능한 한 빠르게 다음 수준의 보호 상태로 복귀할 수 있습니다. 우선순위가 지정된 리빌드 프로세스는 시스템이 완전한 이중화 상태가 될 때까지 계속됩니다. 반면, 복제된 시스템에서는 미러링된 서버만 복구 프로세스에 참여하므로 성능에 큰 영향을 미칩니다. 삭제 코딩도 이와 유사한 문제가 있으며, 서버의 일부만 복구에 참여합니다. WEkaFS는 복구 속도를 사용자가 설정할 수 있고 리빌드 전용 네트워크 트래픽의 양을 언제든지 변경할 수 있어 관리자는 어플리케이션 성능과 복구 시간 간의 최적의 균형을 결정할 수 있습니다.

전력 공급 장애와 엔드투엔드 데이터 보호

WekaFS는 데이터 일관성을 보장하기 위해 체크섬(checksum) 프로세스를 사용합니다. 체크섬은 읽기와 쓰기 모두에 대해 엔드투엔드 데이터 보호 기능을 제공합니다. 체크섬은 쓰기 시 생성되고 읽기 시 유효성이 검증됩니다. WEKA는 항상 데이터와 체크섬 정보를 서로 다른 물리적 미디어에 별도로 저장하여 보호 수준을 향상시킵니다.

WekaFS는 전원 장애로 인한 데이터 손실에 대비하여 추가적인 데이터 무결성 기능을 제공합니다. 클라이언트의 쓰기 작업에 대한 확인이 완료되면 저널링 프로세스를 통해 서버 장애나 데이터센터 전체의 전원 장애로부터 안전하게 보호됩니다. WEKA의 혁신적인 데이터 레이아웃과 알고리즘은 전체 파일시스템 일관성 검사(FSCK)를 수행할 필요가 없기 때문에 데이터센터 전체에 전원 고장이 발생해도 몇 분 안에 복구할 수 있습니다. 대부분의 다른 파일시스템의 경우, FSCK 프로세스 복구 시간은 복구되는 파일시스템의 크기에 비례합니다. 대규모 배포에서는 복구에 수일 또는 수주가 소요될 수 있습니다.

자동 데이터 리밸런싱

WekaFS는 WEKA 클러스터의 성능, 내구성 및 용량 상태를 예방적으로 모니터링하고 관리합니다. 이를 통해 시스템은 호스트의 이용률 수준(성능 및 용량)을 계산하여 클러스터 전체에 데이터를 자동으로, 투명하게 재분배하여 핫스팟을 방지합니다.

WEKA는 용량과 사용량 변화에 따라 클러스터 성능과 데이터 보호를 균형 있게 유지할 수 있는 장점이 있습니다. 또한 기존 서버에 SSD를 추가하거나 클러스터에 더 많은 서버를 클러스터에 추가할 때 자동으로 리밸런싱하여 데이터 마이그레이션에 필요한 비용 소모적인 다운타임 없이도 성능, 내구성 및 용량을 향상시킵니다. 각각의 SSD 용량을 일치시킬 필요가 없기 때문에 새로운 기술을 활용하고 SSD 가격 하락에 따른 비용을 절감할 수 있습니다.

컨테이너 스토리지 통합

컨테이너 스토리지 인터페이스(CSI)는 컨테이너화된 워크로드를 위한 공유 파일 스토리지를 프로비저닝하고 관리하기 위해 개발된 표준입니다. 쿠버네티스(Kubernetes)용 WEKA CSI 플러그인은 쿠버네티스 환경의 논리적 볼륨(퍼시스턴트 볼륨)과 스토리지 간 인터페이스를 제공하여 고객이 무상태 WEKA 클라이언트를 배포하여 스토리지를 적절한 컨테이너에 연결할 수 있도록 합니다. CSI 플러그인은 (관리자가) 퍼시스턴트 볼륨을 통해 Kubernetes pod 볼륨을 프로비저닝하거나 퍼시스턴트 볼륨 클레임을 통해 동적으로 프로비저닝할 수 있습니다. 이 기능은 컨테이너화된 워크로드를 클라우드로 이동하거나 여러 쿠버네티스 클러스터 간에 데이터를 공유하는 프로세스를 간소화합니다. CSI 플러그인은 컨테이너화된 어플리케이션의 공간 소비를 관리하기 위해 할당량 사용을 지원합니다.

멀티테넌트 조직

WekaFS는 계층적 액세스 제어를 제공하는 멀티테넌시의 요소 중 하나인 조직을 지원합니다. 데이터는 조직 수준에서 관리되며 해당 조직 그룹의 구성원에게만 표시될 수 있도록 액세스가 분리될 수 있습니다. WekaFS는 최대 64개의 조직을 지원할 수 있습니다. 조직 관리자는 조직 내에서 데이터를 제어하는 논리적 엔티티(logical entity)를 관리합니다. 반면, 클러스터 관리자는 조직을 생성하고, 조직 관리자를 정의하며, 조직을 삭제하고, 조직 파일시스템의 용량 사용량을 모니터링할 수 있습니다.

용량 할당량

앞서 언급한 바와 같이, WekaFS는 다양한 방법으로 조직의 용량 사용률을 관리합니다.

• 조직 수준 할당량을 통해 그룹은 자체 파일시스템과 용량을 관리할 수 있습니다. WekaFS는 최대 64개의 조직을 지원합니다.
• 파일 시스템 수준의 용량은 서로 다른 프로젝트나 부서가 각각 할당된 용량을 확보할 수 있도록 합니다. WEKA 파일시스템은 단일 스토리지 네임스페이스에서 최대 1024개의 파일시스템을 지원합니다.
• 디렉토리 수준의 할당량은 프로젝트 디렉토리당 할당량을 제공하며, 단일 파일시스템 내에 다수  프로젝트가 있을 때 유용합니다. 할당량은 하드 또는 소프트 할당량으로 권고 수준에서 설정할 수 있습니다.

서비스 품질

WEKA 클라이언트는 QoS 형태로 추가적인 성능 관리 기능도 제공합니다. 이 기능은 선호 처리량 및 최대 처리량을 설정할 수 있는 제한 기능입니다. 클라이언트는 선호 성능 값에 최대한 가깝게 제한하려고 하지만 리소스가 있다면 최대치까지 버스팅할 수 있습니다.. 이를 통해 WekaFS에 액세스할 때 어플리케이션별 성능 관리가 가능합니다. 할당량 및 조직 제어와 함께 사용 시 WEKA 시스템 내에서 세밀한 리소스 관리가 가능합니다.

인증 및 액세스 제어

WekaFS는 사용자 수준과 클라이언트-서버 수준에서 인증 서비스를 통하여 사용자 또는 클라이언트의 데이터 조회 및 접근 권한을 검증합니다. WekaFS는 읽기 전용 또는 읽기-쓰기 등 다양한 인증 마운트 모드를 허용하며, 파일시스템 수준에서 정의됩니다.

인증된 마운트는 조직 수준에서 정의되며 암호화 키로 암호화됩니다. 적절한 키를 가진 클라이언트만 인증된 마운트 지점에 액세스할 수 있습니다. 이 방법은 조직의 특정 하위 집합에 대한 액세스를 대폭 제한하고 적절한 암호화 키를 가진 클라이언트에게만 액세스를 제한하여 보안을 강화합니다. WekaFS는 다음과 같은 기능을 지원합니다:

• LDAP (Lightweight Directory Access Protocol)는 다양한 플랫폼에서 디렉토리 서비스를 제공하는 네트워킹 프로토콜입니다.
• Active Directory는 네트워크 리소스에 대한 정보를 저장할 수 있는 디렉터리 서비스로 Microsoft에서 구현한 LDAP입니다. 주로 클러스터에 가입하려는 사용자 및 그룹의 인증에 사용됩니다.
• WekaFS는 역할 기반 액세스 제어(RBAC)를 통하여 사용자 및 관리자에게 다양한 수준의 권한을 제공합니다. 사용자에 따라 전체 액세스 권한이 부여되거나 읽기 전용 권한이 부여될 수 있습니다.

모든 WEKA 시스템 사용자는 다음 중 하나의 정의된 역할을 가집니다.

클러스터 관리자: 일반 사용자에 대한 추가 권한이 있는 사용자로 다음과 같은 권한이 포함됩니다:

• 새로운 사용자 생성
• 기존 사용자 삭제
• 사용자 비밀번호 변경
• 사용자 역할 설정
• LDAP 구성 관리
• 조직 관리

또한 클러스터 관리자가 WEKA 시스템 클러스터의 액세스 권한을 잃는 상황이 발생하지 않도록 클러스터 관리자에게 다음과 같은 제한이 적용됩니다:

• 클러스터 관리자는 자신을 삭제할 수 없습니다.
• 클러스터 관리자는 일반 사용자 역할로 자신의 역할을 변경할 수 없습니다.

조직 관리자: 클러스터 관리자와 유사한 권한을 가진 사용자이지만 이 권한은 조직 수준으로 제한됩니다. 조직 관리자는 조직 내에서 다음을 수행할 수 있습니다:

• 새로운 사용자 생성
• 기존 사용자 삭제
• 사용자 비밀번호 변경
• 사용자 역할 설정
• 조직 LDAP 구성 관리

또한 조직 관리자가 WEKA 시스템 클러스터의 액세스 권한을 잃는 상황이 발생하지 않도록 조직 관리자에게 다음과 같은 제한이 적용됩니다:

• 조직 관리자는 자신을 삭제할 수 없습니다.
• 조직 관리자는 일반 사용자 역할로 자신의 역할을 변경할 수 없습니다.

일반: 읽기 및 쓰기 권한이 있는 사용자이며 파일시스템을 마운트할 수 있는 권한만 있습니다:

• 로그인하여 액세스 토큰을 받을 수 있습니다.
• 자신의 비밀번호를 변경할 수 있습니다.
• UI에 액세스하거나 다른 CLI/API 명령을 실행할 수 없습니다.

읽기 전용: 읽기 전용 권한이 있는 사용자

S3: S3 명령 및 API를 실행할 수 있는 사용자이며 해당 S3 IAM 정책의 한도 내에서 작업할 수 있습니다.

전송 중 및 저장 중 암호화

WekaFS는 클라이언트에서 오브젝트 스토리지 솔루션까지 완전한 엔드투엔드 암호화를 제공하는 가장 강력하며 상용화된 암호화 파일시스템입니다. 암호화는 파일시스템 생성 시 파일시스템 수준에서 설정되며, 중요성에 대한 판단에 근거하여 파일시스템을 암호화할 수 있습니다. 파일이 암호화되면 파일의 기반이 되는 콜드 블록이 오브젝트 스토어 티어로 전송되더라도 데이터는 암호화된 상태로 유지됩니다. WEKA의 암호화 솔루션은 물리적 미디어 도난, SSD의 펌웨어에 대한 저수준 해킹, 네트워크의 패킷 도청으로부터 데이터를 보호합니다. 파일 데이터는 512비트 키 길이를 사용하는 FIPS 140-3 레벨 1 준수 암호화 키인 XTS-AES로 암호화됩니다.

WEKA는 WEKA 클라이언트를 사용할 때 암호화된 파일시스템이 어플리케이션 성능에 미치는 영향이 제한적이라는 것을 입증했습니다.

키 로테이션 및 키 관리

WekaFS는 KMIP(Key Management Interoperability Protocol) 1.2 이상을 준수하는 모든 키 관리 시스템(KMS)과  Hashicorp Vault 독점 API를 지원합니다. 클러스터 키는 KMS에 의해 로테이션됩니다. 파일시스템 키는 KMS에 의해 로테이션될 수 있으며, 새로운 KMS 마스터 키로 다시 암호화됩니다. 파일 키는 파일을 복사하여 로테이션 할 수 있습니다.

오브젝트 스토어의 파일 데이터도 암호화됩니다. 오브젝트 스토어에 스냅 투 오브젝트를 업로드할 때 파일시스템 매개변수 중 하나로 파일시스템 키가 포함되며, KMS를 통해 사용할 수 있는 특수한 “백업 전용” 클러스터 키로 암호화되어 모든 스냅 투 오브젝트 백업 및 복원에 사용됩니다. 스냅샷을 오브젝트 스토어로 전송할 때 데이터는 완전히 보호되며 KMS 시스템을 통해서만 인증할 수 있습니다.

클라우드 오토스케일링

클라우드 네이티브 어플리케이션의 경우, 성능 또는 사용자 요구 사항에 따라 리소스를 동적으로 확장 및 축소할 수 있는 오토 스케일링 기능을 통해 완전히 유연한 클라우드 탄력성을 제공합니다. WekaFS는 AWS에서 EC2 오토 스케일링 그룹을 지원하여 최대 수요 기간에는 클러스터를 자동으로 확장하고 필요하지 않을 때는 자동으로 축소할 수 있습니다. Google Cloud Platform (GCP)의 경우, 오토 스케일링은 테라폼(Terraform)에 의해 클라우드 함수가 트리거되어 수행됩니다. Oracle Cloud Infrastructure(OCI)와 Microsoft Azure의 경우, WEKA의 다른 사용자 정의 통합을 사용하여 오토 스케일링 기능을 제공합니다. 또한 오토 스케일링과 함께 파일시스템의 씬 프로비저닝을 사용하여  클러스터 확장 시 파일시스템의 가용 용량을 자동으로 늘리고 클러스터 축소 시  필요에 따라 자동으로 축소할 수 있습니다.

컨버지드  

컨버지드 배포(그림 10)에서 WEKA는 표준 AMD 또는 Intel x86 기반 어플리케이션 서버 또는 퍼블릭 클라우드 인스턴스에 통합됩니다. 스토리지 및 컴퓨팅 리소스를 어플리케이션 및 데이터와 단일 빌딩 블록으로 결합하여 다양한 워크로드에 매우 최적화된 데이터센터 솔루션을 제공합니다. 이 배포 모델은 외부 스토리지의 필요성을 없애고 하드웨어 설치 공간과 전력을 줄이면서 성능, 가용성, 용량을 높여 경제적인 통합 어플리케이션 기반 솔루션을 구축합니다. WekaFS는 스토리지 리소스를 분할하여 컨테이너에 있는 리소스만 활용하고 나머지 리소스는 어플리케이션에서 사용할 수 있습니다. 이 배포 모델은 로컬 NVMe 디바이스가 있는 GPU 서버 클러스터에 많이 사용 사용됩니다.

전용 스토리지 서버

WEKA는 모든 시스템 리소스가 스토리지 서비스에 전용되고 어플리케이션이 별도의 컴퓨팅 인프라에서 실행되는 전용 스토리지 서버(그림 11)로 구성될 수 있습니다. 이 모드는 어플리케이션 중단이 스토리지 서비스에 영향을 주지 않기 때문에 고객들이 가장 많이 사용합니다.

네이티브 퍼블릭 클라우드

WEKA는 Amazon Web Services (AWS), Google Cloud Platform (GCP, Oracle Cloud infrastructure (OCI), Microsoft Azure 등 다양한 퍼블릭 클라우드 하이퍼스케일러에서 사용할 수 있습니다. 배포 아키텍처는 각 클라우드에 따라 다르지만 일반적으로 온프레미스 배포와 매우 유사합니다. 서버 구성(EC2, OCI Compute Shape, GCP Compute Engine 등)을 선택하고, NVMe 장치가 컴퓨팅 리소스에 있거나 연결되어 있는지 확인하고, 네트워킹을 할당하고, 클러스터를 구축합니다. WEKA는 클라우드에서 컨버지드 및 전용 스토리지 배포 모델을 모두 지원합니다. 연산 집약적인 워크로드 또는 GPU 기반 인스턴스를 활용하려면 전용 스토리지 서버 모드를 사용하는 것이 가장 좋습니다. 추가적으로 저비용, 고용량 스토리지가 필요한 경우, S3 호환 오브젝트 스토어로의 자동 티어링 기능을 사용할 수 있습니다. AWS S3, Google Cloud Storage, Oracle 오브젝트 스토리지, Azure 블롭(blob)과 같은 S3 호환 오브젝트 스토어를 활용할 수 있습니다. 데이터를 클라우드로 버스트하거나 마이그레이션하는 경우, WEKA 스냅샷-오브젝트 기능을 활용하여 데이터를 이동할 수 있습니다. WEKA는 퍼블릭 클라우드에서 가용 영역에 확장을 지원하여 복원력을 향상시킵니다. 그림 12는 AWS 퍼블릭 클라우드에서의 일반적인 WekaFS 배포 모습입니다. GCP, OCI, Azure의 경우도 컴퓨팅 및 스토리지 서버에 사용되는 용어는 다르지만 구조는 유사합니다.

클라우드에서의 성능은 네트워크 속도뿐만 아니라 WEKA 클러스터의 NVMe 장치 개수와도 밀접한 관련이 있습니다. 최상의 성능을 위해 WEKA 또는 파트너 시스템 엔지니어와 협력하여 사이징 추천을 받으시기 바랍니다.

Standard Performance Evaluation Corporation: SPEC.org

SPEC SFS® 2014 벤치마크는 파일 서버 처리량과 응답 시간을 측정하는 Standard Performance Evaluation Corporation (SPEC) 벤치마크 스위트의 버전으로, 다양한 벤더 플랫폼의 성능을 비교할 수 있는 표준화된 방법을 제공합니다.

WekaFS는 데이터베이스, 가상 데스크톱 인프라 (VDI), 전자 설계 자동화 (EDA), 비디오 데이터 수집 (VDA) 부문에서 리더의 자리를 차지하고 있으며, 소프트웨어 빌드에서는 근소한 차이로 2위를 기록하고 있습니다.

다음 그림 (그림 14)은 WEKA 데이터베이스 성능을 보여줍니다. WekaFS는 4480개의 데이터베이스를 지원했으며, 이는 다음 순위의 시스템보다 2배 더 많은 수치로, 전체 응답 시간은 340 마이크로초였습니다. https://www.spec.org/sfs2014/results/sfs2014database.html

다음 그림(그림 15)은 WekaFS의 초저지연 성능을 보여줍니다. NetApp AFF A800은 WEKA보다 8% 더 많은 빌드를 지원했지만 지연 시간은 830마이크로초였고, WekaFS의 지연 시간은 260마이크로초였습니다. 즉, WekaFS는 같은 시간에 NetApp보다 3배 이상 많은 소프트웨어 빌드를 완료할 수 있습니다. https://www.spec.org/sfs2014/results/sfs2014swbuild.html

성능 확장

WekaFS의 선형적인 성능 확장성을 확인하기 위해, Amazon Web Services에서 테스트를 진행하여 스토리지 서버를 최소 6대에서 수백 대로 확장하는 과정을 시연했습니다. 아래 그래프(다음 페이지 그림 16)는 WekaFS에서 측정된 완벽한 선형 확장을 보여줍니다. 이 성능은 10GB 네트워크 링크에서 측정된 것이므로 100Gbit 또는 200Gbit 네트워크에서 제공하는 WekaFS의 성능을 대표하는 것은 아닙니다. 다만, 이 수치는 파일시스템의 선형 확장성 측면에서 고려해야 합니다.

AWS 퍼블릭 클라우드에서의 WekaFS 성능을 파악하기 위해 아래 그래프(그림 17)는 100Gbit 네트워킹을 사용하는 i3 인스턴스에서 WekaFS의 4K IOPS 및 대역폭 성능을 보여줍니다. WekaFS는 단 16대의 스토리지 서버로 초당 100GB 이상, 500만 IOPS를 달성했으며 지연 시간은 250 마이크로초로 나타났습니다. 지연 시간 그래프가 균일하게 나타난 것은 확장에 따른 성능 저하가 없으며 스토리지 서버 리소스를 두 배로 늘리면 I/O 성능이 두 배로 향상된다는 것을 보여줍니다.

Performance to GPU Storage

WekaFS는 GPU 집약적인 워크로드에 이상적인 파일시스템입니다. WEKA는 NVIDIA® DGX-1™ GPU 시스템을 위한 참조 아키텍처를 개발했습니다. FIO 테스트는 참조 아키텍처의 I/O 성능의 기준을 제공합니다. 성능 테스트는 단일 DGX-1 시스템에서 수행되어 WekaFS가 호스트로의 단일 100-Gbit InfiniBand 링크에 최소 하드웨어 구성으로 어떤 성능을 제공할 수 있는지를 확인했습니다. 그림 18은 WekaFS가 100Gbit 링크를 완전히 포화시켜 단일 DGX-1 시스템에 초당 10.8GB의 최대 읽기 성능을 제공할 수 있음을 보여줍니다. IOPS 성능 측정 결과, WekaFS는 하나의 100Gbit 네트워크 링크에서 단일 DGX-1 시스템에 250,000 이상의 IOPS를 제공했습니다.

다음 성능 테스트는 단일 GPU 서버에서 다중 GPU 서버로 확장하는 WEKA의 능력을 측정합니다. 아래 그림(그림 19)을 살펴보면 WekaFS가 1대의 NVIDIA DGX-1 시스템에서 9대의 NVIDIA DGX-1 시스템으로 완벽한 선형 확장을 유지했음을 알 수 있습니다. 각 NVIDIA DGX-1에는 8개의 GPU가 있어 총 72개의 Tesla V100 GPU로 확장되었습니다.

최종 성능 테스트 세트(그림 20)는 GPUDirect 스토리지를 활용하여 단일 GPU 서버에 성능을 제공하는 WEKA의 능력을 측정합니다. WekaFS는 단일 NVIDIA DGX-2™ GPU 서버에서 하나의 100Gbit EDR 링크에서 8개의 EDR 링크로 성능을 선형적으로 확장하여 네트워크 대역폭을 포화시켰습니다.

클라우드에서의 성능

Oracle Cloud Infrastructure에서 진행한 테스트 결과는 클라우드에서의 확장 및 최상의 성능을 제공하는 WEKA의 능력을 추가적으로 입증했습니다. 그림 21에서 볼 수 있듯이, 각각 80대, 373대의 서버로 구성된 클러스터에서 FIO 테스트가 두 차례 진행되었습니다. 클라우드 환경에서 일반적으로 기대한 것 것보다 훨씬 높은 성능을 달성했으며, 읽기 속도는 약 2TB/초, 쓰기 속도는 1TB/초에 달했으며, 읽기 IOPS는 1,700만, 쓰기 IOPS는 1,200만을 기록했고, 지연 시간은 200마이크로초 이하였습니다. FIO 대역폭과 FIO IOP 테스트 수행 시 필요한 튜닝 차이는 전혀 없었습니다. 이 결과에 대한 자세한 내용은 https://www.weka.io/blog/oracle-oci/에서 확인할 수 있습니다.