Compute Engine의 파일 서버

저장소 파일러라고도 부르는 파일 서버는 애플리케이션이 머신 간에 공유된 파일을 읽고 업데이트할 수 있는 방법을 제공합니다. 어떤 파일 솔루션은 수직으로 확장되며 하나의 VM에 연결된 저장소로 구성되어 있습니다. 또, 어떤 솔루션은 수평으로 확장되며, 애플리케이션에 하나의 파일시스템 네임스페이스를 제공하는 여러 VM(저장소가 연결됨)의 클러스터로 구성되어 있습니다.

일부 파일 시스템은 기본 POSIX 클라이언트를 사용하지만, 다수의 파일 서버는 클라이언트 머신이 파일 시스템을 마운트하고 로컬로 호스팅된 경우처럼 파일에 액세스할 수 있게 해주는 프로토콜을 사용합니다. 공유 파일을 내보내기 위한 가장 일반적인 프로토콜은 Linux의 네트워크 파일 시스템(NFS), Windows의 공통 인터넷 파일 시스템(CIFS) 또는 서버 메시지 블록(SMB)입니다.

이 솔루션은 파일을 공유하기 위한 다음과 같은 여러 가지 방법에 관해 설명합니다.

모든 Google Cloud Platform 서비스의 성능과 예측 가능성에 있어서 기초가 되는 요소는 Google이 수년에 걸쳐 발전시킨 네트워크 스택입니다. Google은 Jupiter Fabric을 이용하여 귀사의 작업 부하에 영향을 미치지 않고 계속해서 진화할 수 있는 견고하고 확장성 있으며 안정적인 네트워크 스택을 구축했습니다. Google이 내부적으로 네트워크 기능을 개선하고 강화함에 따라 귀사의 파일 공유 솔루션도 성능 추가에 따른 혜택을 얻게 됩니다. Jupiter Fabric에 관한 자세한 내용은 Jupiter Fabric의 발전에 관해 설명한 2015 문서를 참조하세요.

투자 효과를 최대화하도록 도울 수 있는 GCP의 한 가지 특징은 커스텀 VM 유형을 지정하는 기능입니다. 파일러의 크기를 선택할 때 파일러가 공유 구성원이 너무 많지 않게 최적의 성능으로 작동하도록 메모리와 CPU를 적절히 조합하여 선택할 수 있습니다.

또한, 파일 서버의 저장 장치가 필요한 저장소 대역과 IOP, 그리고 네트워크 대역폭을 수신하도록 적절한 Compute Engine 영구 디스크 용량과 vCPU의 개수를 선택하는 일도 중요합니다. VM은 모든 vCPU(최대 개수까지)마다 2Gb/s의 네트워크 처리량을 수신합니다. 영구 디스크의 조정에 관해서는 Persistent Disk 및 로컬 SSD 성능 최적화를 참조하세요.

Cloud Storage도 중복성이 높은 페타바이트 규모의 데이터를 적은 비용으로 저장할 수 있는 좋은 방법이지만 Cloud Storage는 성능과 API가 여기서 설명하는 파일 서버와는 다릅니다.

Compute Engine 영구 디스크

데이터에 하나의 VM만 액세스하면 되거나 시간이 지나면서 바뀌지 않는 데이터가 있다면, Compute Engine의 영구 디스크를 사용할 수 있으며, 파일 서버는 완전히 피할 수 있을 것입니다. 영구 디스크를 사용하면 Ext4 또는 XFS와 같은 파일 시스템으로 포맷하고 읽기-쓰기 또는 읽기 전용 모드로 볼륨을 연결할 수 있습니다. 즉, 우선 특정 볼륨을 특정 인스턴스에 연결하고 필요한 데이터와 함께 이를 로드한 다음, 이것을 읽기 전용 디스크로서 수백 개의 가상 머신에 동시에 연결할 수 있다는 뜻입니다. 읽기 전용 영구 디스크를 사용하는 것이 모든 경우에 적합하지는 않지만 파일 서버를 사용하는 것에 비해 복잡성이 크게 감소할 것입니다.

Compute Engine의 영구 디스크는 확장 및 성능과 비용의 균형을 맞춤에 있어서 유연성을 제공하므로 Google Cloud Platform(GCP)에 데이터를 저장하는 훌륭한 방법입니다. 영구 디스크는 크기를 신속하게 조정할 수도 있어서 적은 비용과 적은 용량 볼륨으로 시작할 수 있으며 용량 확장을 위해 추가 인스턴스 또는 디스크를 가동할 필요가 없습니다. 영구 디스크 처리량과 IOPS는 디스크 용량(그리고 SSD 영구 디스크의 경우 vCPU)에 비례하여 확장됩니다. 즉, 다운타임이 거의 또는 전혀 수반하지 않은 크기 조정을 통해 성능을 확장할 수 있다는 뜻입니다.

영구 디스크의 또 다른 장점은 성능의 일관성입니다. 인스턴스에 연결하는 같은 크기의(그리고 SSD 영구 디스크의 경우 vCPU의 수가 같은) 모든 디스크는 성능 특성이 서로 동일합니다. 프로덕션에 사용하기 전에 영구 디스크를 미리 가동하거나 테스트할 필요가 없습니다.

쉽게 예측할 수 있는 것은 성능만이 아닙니다. 볼륨을 프로비저닝한 후에 고려해야 할 I/O 비용이 없기 때문에 영구 디스크의 비용도 결정하기가 쉽습니다 비용 및 성능 특성이 다양한 세 가지 유형의 디스크를 사용할 수가 있으므로 비용과 성능의 균형을 쉽게 맞출 수가 있습니다.

총 용량이 주요 요건이라면 저비용 표준 영구 디스크를 사용하면 됩니다. 최고의 성능과 지속적인 내구성을 원한다면 SSD 영구 디스크를 사용하면 됩니다.

데이터가 일시적이고 지연 시간이 밀리초 미만이며 IOPS가 많다면, 성능 극대화를 위해 최대 3TB의 로컬 SSD를 이용할 수 있습니다. 로컬 SSD는 인스턴스에 할당된 네트워크 용량을 소진하지 않으면서 DDR2 RAM과 비슷한 속도로 최대 700k IOPS까지 허용합니다.

Compute Engine 인스턴스에 사용할 수 있는 여러 가지 디스크 유형의 비교에 관해서는 블록 저장소에 관한 문서를 참조하세요.

파일러 솔루션을 선택할 때 고려해야 할 사항

파일러 솔루션을 선택할 경우 비용과 성능, 확장성 중에서 취사선택을 해야 합니다. 작업 부하가 잘 정의되어 있다면 결정하기가 더 쉽지만, 안타깝게도 그렇지 않은 경우가 많습니다. 작업 부하가 시간이 지나면서 진화하거나 서로 크게 다른 경우, 솔루션으로 발전할 수 있도록 비용 절약을 버리고 유연성과 탄력성을 취하는 것이 좋습니다. 반면에, 작업 부하가 일시적이고 잘 알려져 있다면 즉각적인 저장소 요구를 충족하기 위해 쉽게 해체하고 다시 만들 수 있는 맞춤형 파일러 아키텍처를 만들 수 있습니다.

먼저 결정해야 할 것 중 하나는 Google에서 관리하는 파일러 솔루션과 지원되는 파트너 파일 솔루션, 그리고 지원되지 않는 솔루션 중에서 어느 것을 유료로 이용할 것인지입니다. 모든 비관리형 솔루션은 장기적으로 볼 때 관리할 인력이 필요하지만, 지원되는 솔루션은 지원되지 않는 솔루션에 비해 필요한 자원이 훨씬 더 적다는 점에 유의하세요.

그 다음으로는 파일러의 내구성과 가용성 요건을 파악해야 합니다. 대부분의 파일러 솔루션은 영역별 솔루션이며 기본적으로 영역에 장애가 발생할 경우 보호 기능을 제공하지 않습니다. 따라서 영역 장애 시 보호해주는 재해 복구 솔루션이 필요한지 생각해보는 것이 중요합니다. 그리고 애플리케이션의 내구성과 가용성 요건을 이해하는 것도 중요합니다. 배포 시 로컬 SSD와 영구 디스크 중에서 어떤 것을 선택하느냐는 파일러 솔루션 소프트웨어의 구성만큼 내구성과 가용성에 큰 영향을 미칩니다. 우수한 내구성, 가용성, 그리고 영역 장애 및 지역별 오류 발생 시 보호를 위해 각 솔루션마다 세심한 계획이 필요합니다.

마지막으로, 데이터에 액세스해야 하는 위치(즉, 영역, 지역, 온프레미스 데이터 센터)를 고려하세요. 온프레미스 액세스와 클라우드 내 액세스를 모두 허용하는 솔루션은 일부에 지나지 않으므로, 데이터에 액세스하는 컴퓨트 팜의 위치가 파일러 솔루션을 선택하는 데 영향을 미칠 것입니다.

파일러 옵션

Elastifile

Elastifile는 GCP와 하이브리드 클라우드에서의 기업 저장소 및 데이터 관리를 간소화해줍니다. Elastifile은 글로벌 데이터에 대한 비용 효과적인 고성능 병렬 액세스를 제공하는 한편, 지능형 객체 계층화를 통해 동적으로 확장 가능한 분산형 파일 시스템으로 엄격한 일관성을 유지합니다. Elastifile을 사용하면 리팩토링이 필요 없이 기존 NFS 애플리케이션과 NAS 워크플로를 클라우드에서 실행하면서도 기업 데이터 서비스의 이점(높은 가용성, 압축, 중복 제거, 복제 등)을 유지할 수 있습니다. 기본적으로 Google Kubernetes Engine과 통합되므로 데이터 지속성, 이동성, 그리고 컨테이너화된 작업 부하를 위한 공유가 원활합니다.

Elastifile은 배포와 확장이 버튼 하나로 가능합니다. 파일 시스템 인프라를 필요할 때 쉽게 만들고 확장할 수 있어서 저장소 성능과 용량이 항상 동적 워크플로 요구사항에 맞게 유지됩니다. Elastifile 클러스터가 확대되면 메타데이터와 I/O 성능이 모두 이에 비례하여 확장됩니다. 이 같은 확장 덕분에 고성능 계산, 분석, 사이트 간 데이터 집계, DevOps 등과 같은 광범위한 데이터 집약적 워크플로를 개선하고 가속화할 수 있습니다. 그 결과, Elastifile은 생명과학, 전자 설계 자동화(EDA), 오일 및 가스, 금융 서비스, 미디어 및 엔터테인먼트와 같은 데이터 중심 산업에서 사용하기에 매우 적합합니다.

Elastifile의 CloudConnect 기능은 POSIX 파일 시스템과 Cloud Storage 사이에서 세밀한 양방향 데이터 전송을 가능하게 해줍니다. 성능을 최적화하고 비용을 최소화하기 위해, CloudConnect는 데이터가 전송되기 전에 압축되고 중복이 제거되게 하며 최초 데이터 동기화 이후에만 변경 사항을 전송합니다. 하이브리드 클라우드 배포에 활용할 경우, CloudConnect는 어떤 온프레미스 NFS 파일 시스템의 데이터도 Cloud Storage에 효율적으로 로드되게 해줌으로써 데이터를 클라우드로 가져오는 비용 효과적인 방법을 제공합니다. 클라우드에 활용할 경우, CloudConnect는 Elastifile 파일 시스템과 Cloud Storage 사이에 비용 최적화 데이터 계층화를 가능하게 해줍니다.

Elastifile 데이터 저장소 및 관리 다이어그램

자세한 내용은 다음 링크를 참조하세요.

Quobyte

Quobyte는 병렬 분산형 POSIX 호환 파일 시스템으로 클라우드와 사내에서 실행되어 페타바이트 규모의 저장소와 수백만 건의 IOPS를 제공합니다. 이 회사는 클라우드에 대한 깊은 기술적 이해를 바탕으로 Quobyte 파일 시스템을 설계하고 구성한 전 Google 엔지니어들에 의해 설립되었습니다.

고객은 생명과학, 금융 서비스, 항공우주 엔지니어링, 방송 및 디지털 제작, 전자 설계 자동화(EDA)에서부터 전통적인 고성능 컴퓨팅(HPC) 연구 프로젝트에 이르는 다양한 산업 분야에서 까다로운 대규모 프로덕션 환경에 Quobyte를 사용합니다.

Quobyte는 기본적으로 모든 Linux, Windows, NFS 애플리케이션을 지원합니다. 기존 애플리케이션, 새로 구현된 애플리케이션, 그리고 개발자는 클라우드든 온프레미스든 동일한 환경에서 작동하거나 작업할 수 있습니다. Quobyte는 NFS보다 더 확실한 보장을 필요로 하거나 분산 설정에 맞게 설계되지 않은 애플리케이션에 캐시 일관성을 추가적으로 제공합니다. 그리고 HPC 애플리케이션은 Quobyte가 여러 클라이언트의 동시 다발적인 고속 읽기 쓰기를 지원하는 병렬 파일 시스템이라는 사실을 활용할 수 있습니다.

분산 파일 시스템인 Quobyte는 노드의 수에 비례하여 IOPS와 처리량을 확장함으로써 클러스터링된 솔루션이나 단일 파일러 솔루션의 성능 병목현상을 피합니다. Quobyte는 기본 클라이언트 소프트웨어를 통해 수천 개의 Linux 및 Windows 클라이언트 가상 머신(VM) 또는 컨테이너화된 애플리케이션에 높은 IOPS에 대한 액세스, 짧은 지연 시간, 그리고 수 GB/s의 처리량을 제공합니다. 이 기본 클라이언트는 모든 저장소 VM과 직접 통신하며 데이터의 여러 복제본을 통해서도 읽기가 가능하므로 추가 지연 시간과 NFS 게이트웨이의 성능 병목 현상을 피할 수 있습니다.

Compute Engine의 Quobyte 클러스터는 분 단위로 생성되고 확대될 수 있어서 관리자가 클라우드에서 전체 작업 부하를 실행하거나 최대 작업 부하를 버스트할 수 있습니다. 하나의 저장소 VM으로 시작해서 추가 용량과 VM을 즉석에서 추가하세요. 그리고 리소스가 더 이상 필요하지 않으면 배포 규모를 동적으로 축소하세요

표준 Linux VM은 Compute Engine의 Quobyte 클러스터를 위한 토대입니다. 대화형 설치 프로그램을 통해 신속하고 쉽게 설치할 수 있습니다. 데이터는 연결된 영구 디스크(HDD 또는 SSD 기반)에 저장됩니다. 한 번의 설치를 통해 두 가지 유형 모두를 여러 가지 성능 등급으로 사용할 수 있습니다. 볼륨 미러링 기능은 볼륨에 대한 원거리 복제된 재해 복구(DR) 사본을 만들 수 있게 해주는데, 멀리 떨어진 지역에서도 읽기 전용 액세스에 이를 사용할 수 있습니다.

모니터링과 자동화가 Quobyte에 내장되어 있어서 수백 개의 저장소 VM으로 이루어진 클러스터를 쉽게 유지할 수 있습니다. 클릭 한 번으로 VM과 디스크를 추가하거나 삭제할 수 있으며 새 리소스가 1분 안에 제공됩니다. 내장된 실시간 분석 기능은 저장소를 가장 많이 차지하는 데이터와 애플리케이션의 액세스 패턴을 식별하는 데 도움을 줍니다.

Quobyte는 www.quobyte.com/get-quobyte에서 직접 무료 45일 테스트 라이선스로 제공됩니다.

Quobyte 파일 시스템의 다이어그램

Quobyte는 수천 개의 클라이언트가 성능 병목 현상 없이 모든 저장소 VM과 직접 통신하도록 지원합니다. 여러 가용 영역 또는 온프레미스 클러스터 사이에 추가적인 볼륨 미러링을 사용함으로써, 읽기 전용 데이터 액세스를 위해 여러 지역 간에 예를 들어 재해 복구를 위해 볼륨을 비동기식으로 복제할 수 있습니다.

Avere vFXT

최대의 읽기 성능을 필요로 하는 작업 부하를 위해, Avere Systems는 최상의 솔루션을 제공합니다. Avere의 클라우드 기반 vFXT 클러스터화 클라우드 파일시스템을 사용하여 사용자에게 페타바이트 규모의 저장소와 수백 건의 IOPS를 제공할 수 있습니다.

Avere vFXT의 다이어그램

Avere vFXT는 파일러일 뿐만 아니라 작업 중인 데이터세트를 컴퓨팅 클러스터와 최대한 가까운 위치에 배치하여 기존 워크플로의 변경을 최소화할 수 있는 읽기/쓰기 캐시이기도 합니다. Avere를 이용하면 Compute Engine의 성능, 확장성, 초당 가격과 더불어 Cloud Storage의 비용 효과성을 보조 기억장치로 사용할 수 있습니다.

또한, Avere는 현재의 온프레미스 사용 공간을 최대한 활용할 수 있게 해줍니다. vFXT와 함께 GCP를 활용할 수 있을 뿐 아니라, Avere의 온프레미스 FXT 시리즈를 사용하여 기존 기기의 저장소와 저장소 배열을 단일 네임스페이스를 갖는 확장 가능한 파일러에 통합할 수 있습니다.

온프레미스 저장소 사용 공간으로부터의 전환을 고려하고 있다면, Avere의 FlashMove 기술을 사용하여 클라이언트의 다운타임이 0인 Cloud Storage로 이전할 수 있습니다. 온프레미스 데이터에 재해 복구 메커니즘을 제공하려고 한다면 FlashMirror 기능을 사용하여 Cloud Storage의 온프레미스 저장소를 복제할 수 있습니다. 짧은 시간 동안 대량의 저장소가 필요한 경우에는 Cloud Storage를 사용하여 작업 부하를 클라우드에 버스트할 수 있습니다. 저장소와 컴퓨팅을 필요한 만큼 사용한 다음에 운영 비용을 지불하지 않고 프로비저닝을 해제할 수 있습니다.

Avere는 SSD와 RAM 같은 빠른 로컬 기기를 사용하여 현재 작동 중인 데이터 세트를 가능한 한 컴퓨팅 기기에 가깝게 캐시합니다. vFXT를 사용하면 Cloud Storage의 글로벌 중복성과 엄청난 규모를 이용하면서도 사용자에게는 사용자의 데이터가 사용자 컴퓨팅 클러스터의 로컬 데이터라는 착각을 계속해서 불러일으킬 수 있습니다.

Avere를 파일러 솔루션으로 사용하려면 Avere에 직접 문의하세요. Avere에 관한 자세한 내용은 Google Cloud Platform 통합 개요를 참조하세요.

단일 노드 파일 서버

단일 노드 파일 서버는 Cloud Marketplace를 사용하여 배포할 수 있습니다. 이러한 배포에는 Grafana를 통한 모니터링이 포함됩니다.

단일 노드 파일 서버의 다이어그램

Cloud Marketplace를 사용하여 단일 노드 파일 서버를 배포할 때 원하는 보조 디스크 유형(표준 또는 SSD)을 구성할 수 있습니다. 또한, 인스턴스 유형과 전체 데이터 디스크 크기도 구성할 수 있습니다. 파일러의 성능은 디스크의 크기와 유형, 그리고 인스턴스 유형에 따라 결정된다는 점을 명심하세요. 디스크의 유형과 크기가 총 처리량을 결정합니다.

파일러가 완전히 배포되고 나면 로컬 서브넷의 어떤 호스트에서도 NFS나 SMB 마운트를 사용하여 공유를 마운트할 수 있습니다. 더 작은 디스크로 시작한 후에 필요에 따라 크기를 조정하여 성능 또는 용량 요구에 따라 확장할 수 있다는 점을 명심하세요.

다운타임을 용납할 수 있다면 인스턴스를 중지하고 인스턴스 유형을 변경한 후 다시 시작하여 파일러를 수직 확장할 수도 있습니다. 단일 노드 파일 서버는 수평으로 확장하여 여러 디스크의 공유 풀을 제공할 수 없지만, 개별 파일러는 필요한 만큼 많이 만들 수 있습니다. 이러한 접근법은 배포를 수행하거나 공유된 파일시스템 백엔드를 기준으로 테스트할 경우에 유용할 수가 있습니다.

단일 노드 파일 서버는 여러 영역 또는 지역에 걸쳐 데이터를 자동으로 복제하지 않지만, 주기적으로 백업을 받기 위해 데이터 디스크의 스냅샷을 만들 수 있습니다. 단일 노드 파일 서버를 위한 공식적인 유료 지원은 없으므로, 이 서버의 운영 비용은 인스턴스, 디스크, 네트워크 비용과 직접 묶여 있습니다. 일반적으로 이 방법은 유지관리가 필요 없을 것입니다.

파일 서버 옵션 요약

다음 표는 영구 디스크와 세 가지 파일 서버 옵션의 특징을 요약한 것입니다.

파일러 솔루션최적의 데이터 세트처리량관리형 지원내보내기 프로토콜고가용성하이브리드
Elastifile수십 TB ~ 1PB 미만수십 Gb/s ~ 수백 Gb/sElastifileNFSv3
Quobyte수십 TB ~ 1PB 미만수백 Gb/s ~ 수천 Gb/sQuobyte기본 Linux 및 Windows 클라이언트, Amazon S3, HDFS, NFSv4/3, SMB
Avere수십 TB ~ 수백 TB수십 Gb/s ~ 수백 Gb/sAvereNFSv3, SMB2
읽기 전용 PD64TB 미만180MB/s ~ 1,200MB/s아니요직접 연결아니요아니요
단일 노드 파일 서버64TB 미만최대 16Gb/s아니요NFSv3, SMB3아니요아니요

Compute Engine 인스턴스에 사용할 수 있는 여러 가지 디스크 유형의 비교에 관해서는 블록 저장소에 관한 문서를 참조하세요.

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...