40TB 서버 구성의 상태 점검

나는 40 년의 컴퓨팅 경험을 가지고 있지만, 이와 비슷한 서버를 구축 할 필요는 없었으므로 이것은 n00b 질문 일 수 있습니다.

다운로드 할 수있는 초 고화질 음악 파일을 제공 할 클라이언트가 있습니다. 이 경우 FLAC 압축 24 / 192Khz = ~ 10GB / 앨범을 의미합니다. (아니요, 제품의 바람직 함, 서버 구성에 대해서만 논의하고 싶지 않습니다.) 카탈로그는 약 3,000 개의 앨범이 될 것입니다. 기본 데이터의 35-40TB 정도.

이 제품은 매우 전문화 된 제품이므로 시장 규모는 상대적으로 작습니다 (생각 : 오디오 시스템에 $ 20,000 이상을 소비하는 사람들). 이는 대부분 서버가 100 % 유휴 상태에있을 것입니다. 1Gbps 연결과 대역폭이 약 $ 20 / TB 인 ColocationAmerica의 우수한 코 로케이션 오퍼링과 같은 것을 얻었으므로 이제는 제품을 배송하기위한 상자를 만들어야합니다.

데이터 액세스 사용 사례는 한 번 쓰기 / 읽기-많이이므로 드라이브 쌍에 소프트웨어 RAID 1을 사용하려고합니다. 이것은 (내가 나를 수 있도록 할 생각 하여 어떤 시스템 관리자는 시스템 (그들은 무료로 스왑 아웃 할)에 붉은 빛을 통지하기 전에 두 번째 드라이브로 다시 시작할 수있는, 온 - 더 - 플라이 실패한 것들에 대한 재구성 예비 드라이브). 대부분의 드라이브가 필요하지 않은 경우 대부분의 드라이브를 절전 / 스핀 다운 상태로 만들 수 있다면 좋을 것입니다.

컴퓨팅 파워에는 많은 것이 필요하지 않습니다. 이것은 파이프에 뚱뚱한 물체를 밀어 넣는 것입니다. 따라서 CPU / 마더 보드는이 개수의 드라이브를 지원할 수있는 한 아주 겸손 할 수 있습니다.

현재 다음 구성을 고려하고 있습니다.

Chasis: Supermicro CSE-847E26-RJBOD1
Drives: 30 4TB SAS drives (Seagate ST4000NM0023 ?)
MB: SUPERMICRO MBD-X10SAE-O w/ 8GB
CPU: Xeon E3-1220V3 3.1GHz LGA 1150 80W Quad-Core Server

그래서, 나는 올바른 방향으로 가고 있습니까, 아니면 이것이 문제에 접근하는 완전히 n00b / 공룡 방법입니까?

몇 가지 사항을 명확히하기 위해 업데이트하십시오.

1. 내가 소유 한 마지막 Sun 제품이 80 년대 후반에 돌아 왔기 때문에 ZFS에 대한 경험이 없습니다. 그것이 올바른지 알기 위해 약간의 RTFMing을 할 것입니다.
2. 파일 이름이 단순한 UUID이고 객체가 드라이브 전체에 걸쳐 균형을 이룰 것이므로 (큰 캐싱 시스템과 같은) 파일 시스템이 필요하지 않습니다. 그래서 저는 이것들을 40 개의 개별 파일 시스템으로 생각했고, RAID 1을 제대로 들었습니다 (그러나 여기서는 무지를 인정합니다).
3. 현재 우리가 기대하는 바는 한 번에 수십 개 이상의 파일을 다운로드 할 가능성이 거의 없으며 대부분의 경우 주어진 파일을 다운로드하는 사람이 정확히 한 명일 것이므로 많은 메모리가 필요한지 모르겠습니다. 버퍼 용. 어쩌면 8GB가 약간 가벼울 수도 있지만 128GB가 에너지를 소비하는 것 이상을 할 것이라고는 생각하지 않습니다.
4. 없습니다 여기에 언급이 별도의 시스템은 다음과 같습니다 거의 완전히 분리 다운로드 마스터는 현재 웹 스토어는, 그 핸들 모든 인증, 관리 인제 신제품, 정책 적용 (결국, 이것은 이다 RIAA의 놀이터가), 임시 URL 생성 (그리고 아마도 트래픽이 예상치를 초과하는 경우), 사용량 추적 및 보고서 생성과 같은 두 가지 이상의 짐승에게 다운로드를 전달합니다. 즉, 이 기계는 Quaaludes에서 gerbils를 사용하여 거의 구축 할 수 있습니다.

ZFS? 이점은 어디에 있습니까?

OK, 나는 여러 ZFS 가이드, FAQ 등을 통해 길을 가고 있습니다. 어리석은 소리를내어 용서하지만 실제로 N RAID1 쌍에 대한 고대의 개념보다 ZFS를 사용 하는 이점 을 이해하려고합니다 . 이 모범 사례 페이지 (2006 년부터)에서는 48 개의 장치 ZFS를 수행 하지 말고 24 개의 2 장치 미러를 수행 할 것을 제안 합니다. 다른 페이지에는 1 (한 개의) ZFS 블록을 전달하기 위해 액세스해야하는 장치 수가 언급되어 있습니다. 또한 객체 당 10GB, 디스크 사용률 80 %에서 4TB 드라이브 당 총 320 개의 파일을 저장하고 있습니다 . 특정 드라이브 장애에 대해 N RAID 1을 사용한 재 구축 시간은 한 장치에서 다른 장치로 4TB 쓰기입니다.ZFS는 어떻게 이것을 개선합니까?

나는 공룡이라는 것을 인정할 것이지만 디스크는 저렴하고 RAID 1이고, 파일 관리 요구는 사소한 것이며 Linux의 ZFS (내가 선호하는 OS)는 여전히 젊습니다. 어쩌면 나는 너무 보수적이지만 생산 시스템을 볼 때 그렇게 굴립니다.

나는 이것에 대해 생각하게 한 당신의 의견에 대해 당신 모두에게 감사합니다. 나는 아직 완전히 결정되지 않았고 돌아와서 더 많은 n00b 질문을해야 할 수도 있습니다.

문제 설명을 바탕으로 문제는 서버만큼 스토리지가 아닙니다. 대용량 스토리지 용량을 잘 처리하도록 설계된 ZFS
와 같은 안정적이고 강력한 파일 시스템이 필요하며 시스템 의 끝 부분을보다 쉽게 ​​관리 할 수 ​​있도록 기본 제공 관리 기능이 있습니다.

의견에서 언급했듯이 스토리지 풀에 대해 ZFS를 사용합니다 (FreeBSD에서 아마도 운영 체제에 가장 익숙하고 ZFS와 함께 오랫동안 입증 된 탄탄한 실적을 가지고 있기 때문에 FreeBSD에서 가능합니다.-두 번째 선택) 잘 테스트 된 ZFS 지원으로 인해 OS는 Illumos 일 것입니다 ).

내가 동의하는 파일을 제공하는 한, 데이터를 네트워크 포트로 내보내는 데 하드웨어 측면에서별로 필요하지 않습니다. CPU / RAM의 기본 드라이버는 파일 시스템 (ZFS)의 요구 사항입니다.
일반적으로 ZFS에는 1GB의 RAM이 필요하고 10TB의 디스크 공간마다 1GB가 필요합니다. (40TB의 경우 ZFS에는 5GB의 RAM이 필요합니다.) 관계는 선형 적이 지 않습니다 (많은 것이 있습니다) ZFS에 대한 좋은 책 / 자습서 / 문서는 환경에 대한 견적을내는 데 도움이됩니다.)
중복 제거와 같은 ZFS 벨과 휘파람을 추가하려면 더 많은 RAM이 필요합니다.

분명히 RAM 요구 사항을 줄이지 않고 위로 올립니다. 정확하지 마십시오. 수학에 5GB의 RAM이 필요하다고 말하면 8GB로 서버를로드하지 마십시오-최대 16GB.

그런 다음 스토리지 박스에서 직접 서버를 실행하거나 (서버 프로세스를 지원하기 위해 해당 박스에 더 많은 RAM이 필요함) 스토리지를 "프런트 엔드"서버에 원격 마운트 할 수 있습니다. 실제로 클라이언트 요청을 제공합니다.
전자는 초기에 저렴하고 후자는 장기적으로 더 좋습니다.

이 조언 이외에도 제가 제공 할 수있는 최선의 제안은 이미 용량 계획 시리즈 질문 ( 기본적으로 "로드 테스트, 로드 테스트 , 로드 테스트 ") 에서 다루고 있습니다.

다중 TB 서버에 ZFS를 사용하고 있으며 견고합니다. OpenIndiana를 사용하여 시작했으며 이제는 FreeNAS로 이동하여 필요한 작업을 수행했습니다.

SAS 확장기와 함께 LSI HBA 카드 (9211-8i가 좋은 기본 카드)를 사용하는 것이 좋습니다 (Super Micro 케이스는 LSI 칩셋을 기반으로하는 통합 SAS 확장기와 함께 주문할 수 있습니다). LSI 펌웨어는 FreeNAS 및 FreeBSD에서 지원됩니다. 적절한 버전을 확인하십시오 (V16은 FreeBSD V9.x에서 좋습니다).

한 번 쓰기가 시스템의 많은 특성을 읽었으므로 ZFS Z2 토폴로지를 사용합니다 (이 크기의 드라이브에는 RAID-5 및 Z1은 피하십시오). 4TB 디스크를 사용하는 경우 풀이 가득 찬 경우 큰 단일 vDev 스토리지의 재 구축 (리 실버) 시간이 오래 걸립니다. 긴 재 구축 시간을 피하려면 vDev를 6 또는 10 그룹으로 정렬하여 풀을 생성하십시오 (FreeNAS 설명서의 권장 사항). 3 개의 6 개의 드라이브 vDev (4TB 드라이브로 가정)로 구성된 풀은 ~ 48TB의 사용 가능한 용량을 가지며 양호한 수준의 내결함성을 제공합니다 (RAID가 백업을 대체하지 않기 때문에 여전히 백업해야 함).

일반적으로 액세스되는 파일의 속도를 높이기 위해 L2ARC 용 SSD 몇 개를 넣을 수 있습니다 (어플리케이션에는 필요하지 않지만 120GB SSD에는 매우 저렴합니다).

언급 한대로 많은 RAM을 사용하십시오. 64GB는 시스템의 다른 하드웨어를 고려할 때 지나치게 비싸지 않습니다. 불행히도 작은 XEON은 32GB 이상을 사용할 수 없습니다. 시도해 볼 수는 있지만 ZFS 문헌에 따르면 더 많은 RAM이 더 좋습니다 (32GB 램과 24TB 용량의 Z2 어레이로 언급 한 XEON을 사용하면 정상적으로 작동합니다).

ZFS의 또 다른 장점은 주기적 스냅 샷을 설정할 수 있다는 것입니다. 이렇게하면 이전 버전을 쉽게 복원 할 수 있으며 스냅 샷은 공간 효율적입니다. 또한 스냅 샷을 다른 데이터 세트 (로컬 또는 원격)에 복제 할 수 있으며 SSH를 통해 보안을 수행 할 수 있습니다.

ZFS 시스템의 안정성이 정말 마음에 듭니다. 나는 또한 그것이 하드웨어 독립적이라는 사실을 좋아한다 !! 드라이브를 볼 수있는 모든 시스템은 풀을 가져올 수 있습니다. 하드웨어 습격으로 발생할 수있는 펌웨어 의존성 등이 없습니다 (더 나은 카드의 문제는 아니지만 HBA 카드보다 비싸고 드라이버 등이 필요합니다).

이 게시물이 오래되면 해결책이있을 것입니다. 그렇다면 무엇을 만들 었는지 말씀해 주시겠습니까?

건배,