25TB 이상의 가치가있는 파일을 파일 시스템에 효율적으로 저장하기위한 팁


11

25TB 가치의 압축되지 않은 로그 파일에 직면하여 25TB의 총 여유 저장 용량을 가진 20 개의 상품 상자를 처분 할 수 있다고 가정하십시오.

이것을 어떻게 저장하겠습니까?.

a) 어떤 분산 파일 시스템을 사용해야합니까?

b) 어떤 압축 / 압축 해제 형식 / 알고리즘?

c) 로그 파일 크기는 모든 텍스트와 공백이 1MB-최대 7MB입니다.

d) 사용법은 a) 사람들이 이전의 것보다 최신 로그 파일을 원하므로 캐싱 시스템에서 사용할 것 b) 사람들은 로그 파일을 삭제하지 않고 읽을 것 c) 사람들은 날짜 범위에 대한 로그 파일 목록을 원함

e) 상품 박스에서 운영되는 운영 체제는 Linux,

f) 백업은 잘 처리하는 스토리지 배열이 있습니다. 따라서 배열에서 데이터를 복원하는 기능이 있습니다.

나는 그들이 파일 시스템에 직접 액세스하기를 원하지 않습니다. 어떻게해야합니까? 이를 위해 REST 기반 API를 어떻게 얻습니까?

2 센트를 절약하고 무엇을 하시겠습니까?

앙 쿠르


상품 상자는 어떤 운영 체제에서 실행됩니까? 내결함성이 필요합니까, 아니면 한 상자에 저장된 모든 데이터를 잃어버린 경우에도 괜찮습니까?
Mark Henderson

@farseeker는 질문에 답변하기 위해 질문을 편집했습니다. 감사합니다
Ankur Gupta

질문을 다시 읽으십시오. 첫 번째 질문은 다음과 같습니다. 25TB의 로그 파일은 어디에 저장되어 있으며 그대로 유지할 수 있습니까?
Mark Henderson

NFS 파일 시스템에서 @farseeker
Ankur Gupta

답변:


7

분산 파일 시스템 닌자는 아니지만 가능한 한 적은 수의 컴퓨터에 가능한 많은 드라이브를 통합 한 후 iSCSI를 사용하여 대부분의 컴퓨터를 하나의 기본 컴퓨터에 연결하려고합니다. 거기서 나는 내결함성이있는 스토리지로 통합 할 수있었습니다. 바람직하게는, 기계 내 (드라이브가 나가는 경우) 및 기계들 (전체 기계의 전원이 꺼진 경우) 내에서 내결함성이있는 것이 바람직하다.

개인적으로 저는 ZFS를 좋아합니다. 이 경우 압축, 중복 제거 및 내결함성 빌드가 도움이됩니다. 그러나 내결함성을 유지하면서 데이터를 압축하는 다른 많은 방법이 있다고 확신합니다.

권장하는 실제 턴키 분산 파일 솔루션을 원한다면 이것이 실제로 끔찍하다는 것을 알고 있지만 그것이 올바른 방향을 가리 키기를 바랍니다.

편집 : 여전히 ZFS를 처음 사용하고 iSCSI를 설정했지만 독일의 Sun에서 ZFS의 내결함성을 보여주는 비디오를 보았습니다. 그들은 3 개의 USB 허브를 컴퓨터에 연결하고 각 허브에 4 개의 플래시 드라이브를 넣었습니다. 그런 다음 하나의 허브가 저장 영역 풀을 중단하지 않도록 각 허브에서 하나의 플래시 드라이브로 구성된 RAIDz 볼륨을 작성했습니다. 그런 다음 4 개의 ZFS RAIDz 볼륨을 함께 스트라이프합니다. 그렇게하면 패리티에 4 개의 플래시 드라이브 만 사용되었습니다. 다음으로 하나의 허브를 뽑아 모든 zpool의 성능을 저하 시켰지만 모든 데이터를 사용할 수있었습니다. 이 구성에서 두 개의 드라이브가 동일한 풀에없는 경우에만 최대 4 개의 드라이브가 손실 될 수 있습니다.

이 구성을 각 상자의 원시 드라이브와 함께 사용하면 패리티가 아닌 데이터를 위해 더 많은 드라이브가 보존됩니다. FreeNAS가 iSCSI를 통해 "원시"방식으로 드라이브를 공유 할 수 있거나 공유 할 수 있다는 소식을 들었 으므로 Linux도 동일한 작업을 수행 할 수 있습니다. 내가 말했듯이, 나는 여전히 배우고 있지만,이 대체 방법은 이전 제안보다 드라이브 패리티 관점에서 덜 낭비 될 것입니다. 물론 ZFS를 사용하는 것이 좋을지 모르겠습니다. 학습 경험이 아닌 이상 무언가를 구축 / 유지 / 수리해야하는 경우 일반적으로 알고있는 것이 가장 좋습니다.

이것이 더 좋기를 바랍니다.

편집 : 파고 들었고 내가 이야기 한 비디오를 발견했습니다 . 허브에 USB 플래시 드라이브를 확산시키는 방법은 2m10에서 시작합니다. 비디오는 스토리지 서버 "Thumper"(X4500)와 디스크를 컨트롤러에 분산시키는 방법을 시연하여 하드 디스크 컨트롤러 오류가 발생해도 데이터는 양호합니다. (개인적으로 나는 이것이 괴짜 재미의 비디오 일 뿐이라고 생각합니다. 나는 Thumper 상자를 직접 갖고 싶지만 아내는 집을 통해 팔레트 잭을 돌리는 것을 좋아하지 않을 것입니다. : D 그것은 큰 상자입니다.)

편집 : OpenAFS 라는 분산 파일 시스템에서 오는 것을 기억했습니다 . 나는 그것을 시도하지 않았으며 그것에 대해 약간만 읽었습니다. 아마도 다른 사람들은 그것이 실제 세계에서 어떻게 처리되는지 알고있을 것입니다.


4

첫째, 로그 파일은 실제로 높은 비율로 압축 될 수 있습니다. 로그 파일이 10 : 1 비율로 압축되는 것을 발견했습니다. 5 : 1 비율로 압축하면 스토리지 용량의 20 % 또는 5GB에 불과합니다.

저장 공간이 충분하면 특정 압축 알고리즘이 그다지 중요하지 않습니다. 당신은 할 수 ...

  • Windows 사용자가 파일에 직접 액세스하는 경우 zip 파일을 사용하십시오.
  • 리눅스를 통해 액세스 할 수 있고 빠른 압축 해제가 중요한 경우 gzip을 사용하십시오.
  • Linux를 통해 액세스 할 수 있고 가능한 가장 작은 파일을 가져야하는 경우 bzip2를 사용하십시오.

더 큰 문제는 사용자에게 이러한 파일에 쉽게 액세스 할 수 있도록하는 방법입니다. 이 중 일부는 시스템 구성 방법에 따라 다릅니다.

단일 머신에 충분한 스토리지를 배치 할 수있는 경우 읽기 전용 Windows 파일 공유와 같이 매우 간단한 작업을 수행 할 수 있습니다. 하위 디렉토리에 파일을 정리하면 준비가 완료됩니다.

이러한 파일에 대해 단일 파일 서버를 만들 수 없으면 분산 파일 시스템 이 필요할 수 있습니다 . Windows에는 필요에 따라 분산 파일 시스템 (DFS)이 있습니다.

요구 사항이보다 발전된 경우 사용자가 로그 파일을 찾아 다운로드 할 수있는 웹 응용 프로그램을 프런트 엔드로 사용할 수 있습니다. 이 경우 프론트 엔드 애플리케이션 서버와 함께 사용하도록 설계된 분산 파일 시스템 인 MogileFS를 사용하는 것이 좋습니다. 대부분의 웹 프로그래밍 언어와 쉽게 통합 할 수 있습니다. 컴퓨터에서 공유 드라이브로 마운트 할 수는 없지만 웹 응용 프로그램의 데이터 저장소로는 최고입니다.


참고 : Windows DFS는 여러 서버의 파일 / 폴더를 동기화 상태로 유지하는 방법입니다. 여러 서버의 스토리지를 단일 스토리지 드라이브로 사용할 수 없습니다. microsoft.com/windowsserversystem/dfs/default.mspx
Scott McClenning

그것에 대해 생각한 후에는 옳습니다. DFS 루트 지점이 다른 컴퓨터에있는 폴더를 가리키는 경우 DFS를 사용할 수 있습니다. 이렇게하면 사용자는 하나의 파일 구조를 볼 수 있으며 데이터가 실제로 어떤 머신에 있는지 알 필요가 없습니다. DFS는 알고 있습니다. 작동합니다. 일반적으로 사람들에게 Windows DFS에 대해 물어 보면 스토리지 공간을 함께 풀링하는 방법이라고 생각하기 때문에 그 결론에 도달하게됩니다. 미안하고 당신의 권리는 효과가 있습니다.
Scott McClenning

2

lessfs 는 중복 제거, 압축 파일 시스템입니다. 전체 문제를 해결할 수는 없지만 백엔드로 살펴볼 가치가 있습니다.


2

NFS를 통해이 폴더를 내 보냅니다

아파치 (문서 루트 아래)를 트리로 실행하여 단일 머신에 마운트

압축을 위해 지퍼를 사용하십시오-좋은 압축 비율, 모든 OS에서 지퍼를 열 수 있습니다

아파치에서 파일 목록-사용자에게 읽기 전용 액세스 권한을 부여합니다 (로그 파일은 편집 할 필요가 없습니다)


1
nfs + httpd에 동의하고 zip에 동의하지 않습니다. gzip은 http와 더 잘 상호 작용합니다.
Tobu

@Tobu의 gzip 주석에 +1-올바른 구성으로 Apache는 gzip으로 압축 된 파일을 웹 브라우저에 제공하여 투명하게 압축을 풀고 표시 할 수 있습니다. 사용자는 압축에 대해 알 필요조차 없습니다.
Christopher Cashell

0

로그 파일 압축에 대해 생각해 본 적이 있습니까? 그런 다음 최종 사용자에게 서비스를 제공하기 전에 프런트 엔드에서 무언가를 압축 해제하십시오. CGI 스크립트 일 수도 있습니다.


0

@ 안쿠 르와 @ 포치. 이 로그를 압축 할 필요성에 강력히 동의합니다.

@ jet 나는 단순한 구성이 더 좋다고 생각합니다. 따라서 최종 사용자를위한 httpd는 이상적입니다. 그리고 백엔드가 될 수 있습니다.

내 의견은-로그를 두 그룹으로 나눕니다-폴더 'old'와 'new'.

httpd의 문서 루트에 병합하십시오. 사전 및 블록 크기가 큰 오래된 아카이브 (xz 또는 7z 아카이브, 모든 OS에 널리 사용됨)에 대해 강력한 압축을 사용하면 아카이브도 견고 할 수 있습니다.

새 파일에는 압축 fs를 사용하십시오. lessfs (rw, 중복 제거 + 가벼운 압축 방법), fusecompress 0.9.x (rw, 가벼움에서 강한 압축 방법), btrfs / zfs, squashfs (가벼운 압축 방법에 대한 가벼운, 일부 중복 제거, 사용) 새로 회전 된 로그의 경우).

압축 된 fs (fusecompress, lessfs, btrfs / zfs)에 로그를 투명하게 쓸 수도 있습니다. 작성중인 로그에 httpd로 R / o 액세스를 제공하십시오. 사용자에게는 투명하고 투명하게 압축 해제됩니다.

fusecompress에 대한 경고 : 1) 0.9.x 만 사용하십시오-안정적입니다. 여기에서 복제 https://github.com/hexxellor/fusecompress

최신 버전은 lzma를 제대로 지원하지 않거나 데이터를 잃습니다.

2) 하나의 파일을 압축하기 위해 1 개의 CPU 코어 만 사용하므로 속도가 느려질 수 있습니다.

일정 시간 (몇 달)보다 오래된 '새'폴더의 각 로그를 다시 압축하고 '이전'으로 이동하십시오.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.