몇 달 전에 우리는 $800 TrueNAS 구축 경쟁. 간단히 말해서 Brian, Ben, Kevin은 800달러를 받고 TrueNAS CORE를 OS로 활용하는 자체 NAS 시스템을 구축했습니다. Western Digital 덕분에 직원들은 스토리지에 대해 걱정할 필요가 없었고 WD는 SSD의 무리 그리고 HDD 옵션 남자들이 선택할 수 있도록. 우리는 우리 팀이 서로 다른 시스템을 구축하는 데 무엇을 할 수 있고 서로 어떻게 비교하는지 확인하고 싶었습니다. 그들은 돈을 쓰고 쓰레기 같은 말을 하고 시스템을 테스트했습니다. 그들이 어떻게 했는지 알아봅시다.
몇 달 전에 우리는 $800 TrueNAS 구축 경쟁. 간단히 말해서 Brian, Ben, Kevin은 800달러를 받고 TrueNAS CORE를 OS로 활용하는 자체 NAS 시스템을 구축했습니다. Western Digital 덕분에 직원들은 스토리지에 대해 걱정할 필요가 없었고 WD는 SSD의 무리 그리고 HDD 옵션 남자들이 선택할 수 있도록. 우리는 우리 팀이 서로 다른 시스템을 구축하는 데 무엇을 할 수 있고 서로 어떻게 비교하는지 확인하고 싶었습니다. 그들은 돈을 쓰고 쓰레기 같은 말을 하고 시스템을 테스트했습니다. 그들이 어떻게 했는지 알아봅시다.
팔로우하지 않은 사람들을 위한 설정으로 여기 또는 다음에서 찾을 수 있는 작은 경쟁에 대한 비디오를 만들었습니다. YouTube 페이지:
예산 TrueNAS CORE 시스템
벤 인턴의 빌드 아마도 가장 많은 DIY 일 것입니다. 그는 Cincinnati Computer Cooperative와 MicroCenter에 가서 모든 부품을 별도로 구입하여 직접 조립했습니다. 그의 부품에는 OCZ GSX600 PSU, ASRock B550 마더보드, G.Skill Ripjaws V 64GB(2 x 32GB) DDR4-3600 RAM, Ryzen 5 3600, Chelsio 111-00603+A0 및 Lian Li Liancool 205 PC 케이스가 포함되었습니다. . 여분의 몇 달러로 남은 돈으로 그는 자신의 빌드에 LED 스트립을 몇 개 던졌습니다.
케빈 Xeon 프로세서 및 ECC 메모리와 함께 HPE MicroServer Gen10 Plus를 활용했습니다. Kevin은 또한 100GbE Mellanox ConnectX-5 카드를 추가하여 다른 빌드를 지원하는 동시에 네트워킹 구성을 더 쉽게 만들었습니다. 다른 빌드는 이중 포트 NIC를 사용하지만 Kevin은 하나의 100GbE 인터페이스만 구성하면 됩니다.
브라이언의 빌드 다른 둘 사이 어딘가에 있습니다. 그는 AMD EPYC 11 SoC 프로세서와 8개의 4GbE 포트를 제공하는 Supermicro M3201SDV-1CT-LN4F 보드로 시작하여 예산을 크게 절감했습니다. RAM Brain의 경우 두 개의 SK 하이닉스 PC2400-1T-RD11-4 DDR8 ECC 500GB DRAM 모듈을 활용했습니다. 그는 또한 Thermaltake 10W PSU와 304GbE 카드를 설치했습니다. 이 모든 것이 Fractal Design Node 10 인클로저 내부에 배치되었습니다. Brian은 환상적인 가격에 찾은 XNUMXGbE 카드를 찾았지만 궁극적으로 TrueNAS 소프트웨어를 인식하거나 작동하지 않을 것이므로 예비 연구실 Emulex NIC로 되돌려야 했습니다. 중국산 중고 DRAM도 문제가 돼 교체해야 했다.
예산 TrueNAS CORE 시스템 – 성능
모두가 여기 있는 진짜 이유를 알아봅시다. 세 가지 중 어느 것이 가장 좋습니까? 세 가지 DIY 빌드 외에도 TrueNAS 미니 우리가 부수적으로 포기하고 있다는 것입니다. iXsystem 빌드는 2개의 HDD와 함께 제공되었기 때문에 RAIDZ5를 사용하고 있습니다. iXsystems TrueNAS Mini X+ 플랫폼은 섀시 크기와 드라이브 지원의 최상의 조합을 제공합니다. 3.5개의 2.5인치 HDD를 지원하며 SSD용 XNUMX인치 베이도 XNUMX개 있습니다. 그렇다면 기준선으로 테스트하지 않는 이유는 무엇입니까? 간단하게 Mini X+는 성능이 아닌 최대 데이터 복원력을 위해 조정되었습니다. 다른 세 개는 이 대결에서 가장 빠르도록 조정되었지만 몇 가지 위험이 따릅니다. iXsystems가 경쟁사를 이기고 싶다면 빌드로 완전히 압도할 수 있습니다.
RAID 구성에 대한 간단한 설명: TrueNAS는 빌드에 따라 여러 가지를 지원합니다. 근본적으로 다른 빌드를 사용했기 때문에 다른 RAID 구성이 있을 것입니다. Ben과 Kevin의 빌드는 XNUMX개의 SSD에서 RAIDZ를 사용하고 Brian의 빌드는 XNUMX개의 HDD에서 미러를 사용합니다.
우리는 이 대결을 위해 SMB 파일 공유 프로토콜만 살펴보았습니다. 언급해야 할 흥미로운 요소 중 하나는 마더보드 및 섀시 구성에 얼마나 많은 중요성이 있는지입니다. 틀림없이 가장 멋져 보이는 Ben의 데스크탑 플랫폼은 3.5인치 드라이브 베이가 XNUMX개뿐이며 지금까지 가장 큰 케이스이기도 합니다.
Brian의 케이스는 냉각에 주의하면서 최대 3.5개의 XNUMX인치 드라이브 베이를 지원하지만 그의 마더보드에는 XNUMX개의 온보드 SATA 포트만 있습니다. 기본 빌드로서의 Kevin의 HPE Microserver 빌드에는 XNUMX개의 베이와 XNUMX개의 포트가 있지만 이것이 바로 플랫폼이 설계된 방식입니다.
스토리지는 다른 모델에서도 약간 다릅니다. Brian의 빌드에는 10개의 2TB WD Red HDD가 있었지만 안타깝게도 M.XNUMX NVMe 포트가 의도한 대로 정확하게 작동하지 않았습니다. Ben과 Kevin의 빌드는 모두 XNUMX가지를 활용했습니다. 4TB WD 레드 SSD.
성능 섹션에서 RAID 구성이 드라이브 선택 자체를 넘어 성능 측정 방법에 큰 역할을 한다는 점에 유의하는 것이 중요합니다. RAIDZ는 RAIDZ2보다 오버헤드가 적고 미러는 RAIDZ보다 오버헤드가 훨씬 적습니다. 즉, RAID 설정은 궁극의 최종 애플리케이션이 무엇인지, 필요한 용량은 얼마나 되는지, 구축하려는 장애 저항성은 어느 정도인지를 고려해야 합니다. 결국, 이러한 결과는 어떤 NAS가 더 빠른지 보여주기 위한 것이 아니라 TrueNAS 구성이 다른 RAID 구성에서 동일한 드라이브를 사용하는 유사한 빌드에서 어떻게 수행되는지 보여주기 위한 것입니다.
엔터프라이즈 종합 워크로드 분석
당사의 엔터프라이즈 공유 스토리지 및 하드 드라이브 벤치마크 프로세스는 스레드당 16개의 대기 대기열이 있는 16개 스레드의 과도한 로드에서 장치를 테스트할 동일한 워크로드로 각 드라이브를 정상 상태로 설정한 다음 정해진 간격으로 여러 번 테스트합니다. 스레드/대기열 깊이 프로필을 사용하여 사용량이 적거나 많을 때 성능을 보여줍니다. NAS 솔루션은 정격 성능 수준에 매우 빠르게 도달하므로 각 테스트의 주요 섹션만 그래프로 표시합니다.
사전 조건화 및 기본 정상 상태 테스트:
- 처리량(읽기+쓰기 IOPS 집계)
- 평균 대기 시간(읽기+쓰기 대기 시간을 함께 평균화)
- 최대 대기 시간(최대 읽기 또는 쓰기 대기 시간)
- 대기 시간 표준 편차(함께 평균화된 읽기+쓰기 표준 편차)
Enterprise Synthetic Workload Analysis에는 실제 작업을 기반으로 하는 4가지 프로필이 포함되어 있습니다. 이러한 프로필은 기업용 드라이브에 일반적으로 사용되는 최대 8k 읽기 및 쓰기 속도 및 70k 30/XNUMX과 같이 널리 게시된 값뿐만 아니라 과거 벤치마크와 쉽게 비교할 수 있도록 개발되었습니다.
- 4K
-
- 100% 읽기 또는 100% 쓰기
- 100% 4K
- 8K 70/30
- 70% 읽기, 30% 쓰기
- 100% 8K
- 8K(순차적)
- 100% 읽기 또는 100% 쓰기
- 100% 8K
- 128K(순차적)
- 100% 읽기 또는 100% 쓰기
- 100% 128K
첫 번째는 4K 읽기/쓰기 처리량 테스트입니다. 읽기의 경우 최고 성능은 Ben의 14,865 IOPS였습니다. Kevin은 11,476으로 595위를 차지했습니다. Brian은 3,868 IOPS로 2,517위를 기록했습니다. 쓰기 부문에서는 Kevin이 923 IOPS로 XNUMX위를 차지했습니다. Ben은 XNUMX IOPS로 XNUMX위를 차지했습니다. Brian은 XNUMX IOPS로 XNUMX위를 유지했습니다.
이 중 대부분은 배포된 RAID 유형으로 귀결되지만 Kevin의 Microserver 대 Ben의 DIY 빌드에서는 IOPS 차이가 각 빌드의 CPU 속도에 영향을 미칩니다.
다음은 4K 평균 대기 시간입니다. 여기서 우리는 위와 같은 배치를 볼 수 있습니다. 읽기에서는 Ben이 17.2ms로 이기고 Kevin이 22.31ms로 429.2위를 차지했으며 Brian이 66.21ms로 훨씬 뒤처졌습니다. 쓰기로 전환하면서 Kevin은 101.66ms로 276.89위를 차지했고 Ben은 XNUMXms로 XNUMX위를 차지했으며 Brian은 XNUMXms로 XNUMX위를 차지했습니다.
4K 최대 대기 시간은 배치에서 약간의 흔들림을 보았습니다. 읽기의 경우 Ben이 263.96ms로 273.44위를 차지했고 Kevin이 1,091.3ms로 바로 뒤를 쫓았으며 Brian이 1,195ms로 2,092.5위를 차지했습니다. 쓰기에서는 Kevin이 2,431.7ms로 XNUMX위, Brian이 XNUMXms로 XNUMX위, Ben이 XNUMXms로 XNUMX위로 떨어졌습니다.
마지막 4K 테스트는 표준 편차입니다. 읽기의 경우 Ben이 5.94ms로 7.11위를 차지했고 Kevin이 171.75ms로 근소한 차이로 뒤처졌으며 Brian이 117.02ms로 Kevin보다 훨씬 뒤처졌습니다. 쓰기에서 Kevin은 201.58로 271.13위를 차지했고 Ben은 XNUMXms로 크게 뒤지지 않았으며 Brian은 XNUMXms로 그다지 뒤지지 않았습니다.
다음 벤치마크는 100% 읽기 및 8% 쓰기 작업에서 16T16Q 로드로 100% 100K 순차 처리량을 측정합니다. Ben의 빌드는 읽기에서 47,699 IOPS로 선두를 차지했고 Kevin은 44,848 IOPS로 근소한 차이로 그 뒤를 쫓았으며 Brian은 29,767 IOPS를 기록했습니다. 쓰기 부문에서는 Ben이 83,866 IOPS로 다시 51,020위를 차지했고 Kevin은 33,448 IOPS로 XNUMX위에 머물렀고 Brian은 XNUMX IOPS로 XNUMX위를 유지했습니다.
16% 16K 쓰기 테스트에서 수행한 고정된 100개 스레드, 4개 대기열 최대 워크로드와 비교할 때 혼합 워크로드 프로필은 광범위한 스레드/대기열 조합에서 성능을 확장합니다. 이 테스트에서는 2스레드/2 대기열에서 최대 16스레드/16 대기열까지 워크로드 강도를 확장합니다. 여기에서 드라이브 유형 및 RAID 구성이 큰 역할을 합니다. 드라이브 오류를 지원하기 위해 추가된 패리티는 성능에 영향을 미칩니다. 처리량에서 Ben은 최고점에서 시작하여 17,317 IOPS로 최고점을 기록했지만 빌드가 끝날 무렵에는 약간 떨어졌습니다. Brian의 빌드가 Kevin보다 높게 시작했지만 Kevin은 두 번째로 그를 능가할 수 있었습니다.
평균 대기 시간으로 15.8개의 StorageReview 빌드는 모두 18.3밀리초 미만의 대기 시간으로 시작되었습니다. 그들이 꽤 가깝게 달리는 동안 Ben의 빌드가 점차 Kevin보다 앞서고 두 사람 모두 Brain의 빌드에서 멀어지는 것을 볼 수 있습니다. Ben은 31.2ms, Kevin은 XNUMXms, Brian은 XNUMXms로 끝났습니다.
최대 대기 시간을 위해 Kevin은 최고로 출발했고 그와 Ben은 221위를 주고받았습니다. 결국 Kevin의 빌드는 285ms, Ben의 빌드는 XNUMXms였습니다. 브라이언은 전반적으로 XNUMX위로 훨씬 뒤쳐져 있었습니다.
표준 편차는 전반적으로 Ben의 빌드를 명확하게 보여줍니다. Kevin은 대기 시간이 약 3배, Brian은 약 4배였습니다.
마지막 Enterprise Synthetic Workload 벤치마크는 장치의 최고 순차 전송 속도를 보여주는 대규모 블록 순차 테스트인 128K 테스트입니다. 읽기에서는 Kevin이 2.32GB/s로 1.81위를 차지했고 Ben은 734GB/s로 바로 뒤를 쫓았으며 Brian의 빌드는 2.77MB/s로 시작 권총을 놓쳤을 것입니다. 기록에서 Kevin은 1.42GB/s로 다시 한 번 1.41위를 차지했으며 Ben과 Brian은 각각 XNUMXGB/s와 XNUMXGB/s로 거의 동률을 이루었습니다.
필요에 맞는 구성 선택…
그래서 누가 이겼어? 실제로 배포에 가장 큰 가치를 두는 항목에 따라 다릅니다. I/O 성능 면에서 가장 빠른 빌드는 드라이브 베이 XNUMX개와 소비자용 CPU/RAM만 있었습니다. ZFS를 사용하면 ECC 메모리와 같은 엔터프라이즈 구성 요소가 고급 데이터 무결성 스택을 사용하기를 원하므로 비생산 배포를 제외한 모든 배포에서 거의 자격이 없습니다.
다음으로 하드웨어 측면에서 필요한 것과 섀시의 증가된 드라이브 베이에 훨씬 더 근접한 Brian의 빌드를 살펴봅니다. 하지만 마더보드는 XNUMX개의 하드 드라이브만 지원합니다. 또한 전원 공급 장치의 여분의 케이블로 가장자리까지 채워졌습니다. 밝혀진 바와 같이 중고 NIC 및 DRAM을 eBay로 이동하라는 요청은 좋지 않았으며 전반적인 시스템 안정성은 분명히 "변동" 및/또는 "버벅거림" 범주로 한 단계 반 정도 떨어졌습니다.
DIY 군중의 경우 기성 마이크로 서버를 사용하여 Kevin의 빌드로 귀결되었습니다. Microserver는 설치 공간이 더 작고 진입 가격이 더 낮습니다. 대역 외 관리를 위한 iLo와 같은 모든 엔터프라이즈 구성 요소와 항목도 있습니다. 하지만 이 시스템은 베이가 4개뿐이고 모두 SATA이므로 스토리지에 한계가 있으므로 고속 성능은 없습니다. 그럼에도 불구하고 DIY 예산 TrueNAS CORE 시스템을 롤링할 때 저항이 가장 적은 경로를 제공합니다.
TrueNAS Mini일까요?
어디 TrueNAS 미니 X+ 이것에 맞습니까? 성능을 위해서는 그렇지 않습니다. 우리가 가지고 있는 특정 빌드는 데이터 복원력을 위한 것입니다. 그러나 Mini X+에는 10GbE 온보드와 같은 몇 가지 멋진 기능이 있습니다. Mini +는 의심의 여지 없이 총 7개의 드라이브 베이와 함께 가장 많은 스토리지 용량 지원 및 유연성을 제공합니다.
성능 측면에서 DIY 시스템의 순위를 매기는 것 외에도, 이 콘테스트는 TrueNAS CORE OS와 제한된 예산 내에서 무엇을 할 수 있는지에 대한 깔끔한 그림을 그립니다(이 작업의 일부로 WD에서 스토리지를 얻었습니다). 기성 장치를 구입하는 것은 공급업체의 안심(지원)이 필요한 소기업에게는 항상 가장 안전한 방법입니다. 분명히 우리 빌드 중 일부는 DIY 경로로 갈 때 약간의 어려움을 겪었습니다.
생산 사용 사례라면 턴키 시스템의 가치는 아무리 강조해도 지나치지 않습니다. iXsystems Mini +는 가격이 더 높지만 DIY 플랫폼보다 3개의 추가 디스크를 지원하고 구성 요소 드라이버 지원에 대해 의문의 여지가 없습니다. 물론 DIY 빌드로는 제공할 수 없는 하드웨어 및 소프트웨어에 대한 엔터프라이즈 지원도 있습니다. 결국, 그것은 당신이 원하는 것에 달려 있습니다. TrueNAS CORE는 거의 모든 하드웨어를 처리할 수 있을 만큼 유연합니다.
iXsystems 덕분에 TrueNAS Mini를 무료로 드립니다. 여기에 등록하는 방법에 대한 자세한 내용.
아래의 성능 하이라이트 비디오에서 하이라이트를 확인하십시오.
TrueNAS 리소스
StorageReview에 참여
뉴스레터 | 유튜브 | 링크드인 | 인스타그램 | 트위터 | 페이스북 | 틱톡 서비스 | RSS 피드
