이메일 저장을 고려하고 있습니다. 이 스토리지 시스템은 내 개인 클라우드(이미 복제됨)에서 실행되므로 복제에 신경 쓰지 않습니다.
저는 2가지 옵션을 생각하고 있습니다.
1- 몇 개의 "디스크"(클라우드 볼륨)를 생성하고 다중 디스크에 Btrfs 파일 시스템을 생성합니다. 파일 시스템이 가득 차면 더 많은 "디스크"를 만들고 다음을 통해 btrfs 파일 시스템에 추가합니다.
btrfs device add /dev/vdX /mnt
btrfs filesystem balance /mnt
이 마운트 지점(/mnt)은 NFS를 통해 노출되며 내 Dovecot 서버는 이 내보내기를 마운트하고 여기에 이메일을 저장합니다.
2- 몇 개의 "디스크"(클라우드 볼륨)를 생성하고 이러한 디스크 전체에 GlusterFS 분산 볼륨을 생성합니다. 파일 시스템이 가득 차면 더 많은 "디스크"를 생성하고 GlusterFS 분산 볼륨에 새 "디스크"를 추가하여 균형을 재조정합니다. 내 Dovecote는 glusterfs-client를 사용하여 이 볼륨을 마운트하고 여기에 이메일을 저장합니다.
(반복: 내 "디스크", 프라이빗 클라우드의 볼륨, 내부에 복제되었기 때문에 복제가 필요하지 않습니다.)
어떤 옵션이 더 좋다고 생각하시나요?
- 성능? (많은 작은 읽기/쓰기 I/O)
- 안정적인?
- 유연한?
답변1
메일 서버의 I/O 패턴(읽기/쓰기)을 고려해야 합니다.많은작은 파일을 가능한 한 빨리. IMHO라는 많은 클라이언트를 처리할 때 두 가지 변형 모두 실제로 적합하지 않습니다.
두 FS 모두 충분히 빠르지 않으며 특히 GlusterFS의 잠금 오버헤드가 상당할 것 같습니다. 그런 다음 자체 오버헤드가 있는 NFS를 사용하여 다른 레이어를 추가합니다. 그 대신 가능한 한 적은 오버헤드와 빠른 파일 시스템을 사용하여 메일 저장소를 연결하려고 합니다. 일반적으로 이는 가능한 한 물리적 스토리지에 직접 연결하는 것을 의미하지만 "프라이빗 클라우드"와 같은 헛소리 빙고 용어 뒤에 아키텍처를 숨기므로 무엇이 가능할지 알 수 없습니다.
시도해 볼 수 있는 한 가지 접근 방식은 iSCSI를 통해 스토리지를 메일 서버로 내보낸 다음 많은 작은 파일로 빠른 FS를 사용하는 것입니다. 정말 중요한 경우 LVM을 사용하여 해당 FS에 공간을 쉽게 추가할 수 있습니다. 추가 iSCSI 볼륨 형태(일부 오버헤드가 다시 추가됨)
무엇을 시도하든 다양한 변형을 벤치마킹하고 필요한 성능을 얻을 수 있는지 확인해야 합니다.
답변2
위의 두 가지 중 하나를 선택해야 한다면 NFS가 더 바람직하다고 생각합니다.
OpenStack 볼륨은 여전히 중앙 스토리지에서 마운트되므로 GlusterFS는 설정에서 분산 파일 시스템으로서의 모든 이점을 잃습니다. NFS 잠금이 단일 서버에서 수행되는 동안 분산 파일 잠금에 신경을 써야 하기 때문에 더 안정적이지도 스마트하지도 않습니다.
여러 장치의 저장소를 결합하는 것이 좋은 생각인지 잘 모르겠습니다. 또는 높은 수준의 OpenStack 볼륨 서비스 기능을 건너뛰고 NFS에서 내보낸 LVM(/ZFS/SAN) 볼륨 형식의 스토리지를 직접 노출하는 것을 고려할 수 있습니다. 이렇게 하면 불필요한 iSCSI 수준이 제거되고 주 저장소에 충분한 여유 공간이 있는 한 필요에 따라 메일 저장 공간을 늘릴 수 있습니다.