GlusterFS의 구성 방식과 장단점

스파클링소다 3.0에서는 GlusterFS를 사용하는 고객사가 많습니다.

특히 각 고객사마다 구성 방식에 차이를 띄는 곳이 있는데 GlusterFS의 특징과 저장 방식에 대해 알아보겠습니다.

GlusterFS의 특징

(GlusterFS의 공식 로고)

GlusterFS는 Software Defined Storage로, 일종의 Scale-Out한 NAS(Network Attached Storage)파일 시스템입니다.

오픈 소스의 분산 파일 시스템 중 하나로, 대용량 데이터 스토리지 및 관리를 위해 설계되었습니다.

✓ 주로 높은 확장성과 가용성이 요구되는 환경에서 사용됩니다.

 

GlusterFS의 특징:

1. 분산 및 복제: 데이터를 여러 서버와 스토리지 시스템에 분산시켜 저장하여 데이터 확장성과 고가용성을 제공합니다.
2. 탄력성: GlusterFS 클러스터에 새로운 노드를 쉽게 추가하거나 제거할 수 있습니다.
3. 쓰기 기반 복제: 데이터를 여러 서버에 자동으로 복제하여 오류 복구 및 가용성을 향상시킵니다.
4. 플랫폼 호환성: Linux, macOS, Windows 등 다양한 플랫폼에서 사용할 수 있습니다.

장점:

1. 확장성: GlusterFS는 대용량의 데이터 스토리지를 지원하며, 클러스터에 추가 노드를 쉽게 통합할 수 있어 확장성이 뛰어납니다.
2. 고 가용성: 여러 레플리카를 통해 데이터 손실 위험을 줄이고 시스템 장애 시 빠른 복구가 가능합니다.
3. 파일 시스템 호환성: GlusterFS는 기존 파일 시스템과 호환되며 Linux FUSE 인터페이스를 통해 호환 파일 시스템으로 탑재됩니다.

fuse.glusterfs 시스템 = 별도의 스토리지나 시스템과 관계없이 디렉토리 그대로 GlusterFS 파일 시스템으로 사용이 가능

단점:

1. 복잡성: GlusterFS의 설정과 관리는 초기에 복잡한 작업이 될 수 있으며, 잘못 구성된 경우 성능 저하가 발생할 수 있습니다.
2. 용량이 작은 파일들에 대한 성능 저하: GlusterFS는 대규모 스토리지를 다루기 때문에 용량이 작은 파일에 대한 성능이 최적화되지 않을 수 있습니다.
3. 네트워크 병목: 트래픽이 집중되는 경우, 네트워크 구간에서 병목 현상이 발생할 수 있습니다.

GlusterFS의 주요 특징

GlusterFS는 파일을 저장할 때 메타데이터 서버가 필요가 없습니다.

각 서버들이 자체적으로 로컬 파일 시스템을 가지고 있기 때문입니다. (그림에서는 Ext3)

대표적 경쟁 시스템인 Hadoop의 경우 아래와 같이 메타데이터 서버에 요청을 하여 파일을 탐색하고 제어합니다.

GlusterFS는 파일을 저장할 때 GlusterFS 서버의 로컬디스크에 지정된 폴더(Gluster에서는 이를 Brick이라고 합니다.)들에 클라이언트가 보낸 파일을 변경없이 그대로 저장합니다.

대부분의 분산 적재 파일 시스템들의 경우 여러곳에쪼개서 저장하기 때문에 직접 엑세스 가능한 마운트 포인트로 접근해야만 올바른 파일을 탐색할 수 있습니다.

-

본사에서 자주 사용하는 NEXUS의 경우도 metadata를 통해 파일을 제어합니다.

따라서 메타데이터가 망가지면 파일의 대한 모든 정보를 잃어버리게 됩니다.

► NEXUS 레포지토리의 content 데이터

hadoop의 경우에도 metadata 서버가 해당 파일의 제어를 관여하기 때문에 실제 데이터가 그대로 저장되지 않습니다.

► Hadoop의 데이터 스토리지 저장 경로

GlusterFS의 Brick디렉토리

► 따라서 실제 Brick 디렉토리로 접근시 실제 파일들이 그대로 들어있는 것을 확인 할 수 있음.

즉 모든 파일들의 정보는 Glusterfs 클라이언트가 Volume을 Mount하면 그때 볼륨에 속한 Glusterfs 서버의 Brick으로 지정된 폴더에서 읽어와 한 폴더내에 일종의 가상으로 파일들을 보여줍니다.

따라서 클라이언트도 Metadata 서버에 파일 정보를 물어볼 필요없이 자신이 마운트한 볼륨의 정보만 알면 되기 때문에  클라이언트가 마운트 볼륨에 접근시 요청할때 메타 데이터들을 받아오게 됩니다.

GlusterFS의 이러한 특징 때문에 Mount 포인트로 접근하나 Brick 경로로 접근하나 동일한 파일이 있는 것으로 오해하기 쉽지만, 모든 노드에 각각 동일한 메타데이터를 가지는 것과 실제 파일이 저장되는 방식과는 다른 의미입니다.

클라이언트는 Mount Point를 통해 접근하지 않으면 실제 Gluster 그룹에 묶인 서버 스토리지들에 데이터 신뢰성을 잃게 되는데 그 이유를 설명하기 전에 GlusterFS의 분산 저장 방식의 종류를 먼저 살펴봅니다.

GlusterFS의 구성 방식 1 - Replicated Volume 방식

Replicated Volume 방식은 스파클링소다에서 주로 사용하는 복제 저장 방식입니다. (RAID 1 개념)

(1 x n)

Mount 포인트로 데이터가 들어올 경우 n개의 서버 스토리지에 모두 동일하게 복사되어 들어갑니다.

모든 서버에 동일하게 저장되기 때문에 굳이 마운트 포인트를 통하지 않고 Brick 데이터로 접근해도 파일 탐색이 가능하지만, 파일의 삭제 및 변경이 이루어질 시 다른 노드 스토리지에 즉시 반영이 되지 않을 수 있습니다.

또한 Replicate 볼륨의 가장 큰 특징으로는, 아무리 많은 저장소를 이어 붙여도 항상 용량이 증가 되지 않고 저장소 1개 분량의 용량으로만 표기 됩니다.

ex)

4TB 하드디스크를 1000개 이어 붙여도 서버는 총 4TB의 용량만 사용할 수 있음.

= 모든 데이터가 1000개에 동일하게 복제되서 저장되기 때문에 scale-out 용량 증설이 불가능.

> 하나의 서버가 다운되도 다른 서버에서 파일을 복제 저장하고 있어서 서버 스토리지가 확장 될 수록 파일 안정성이 점차 증가함. (GlusterFS 힐링 기능으로 소실 된 파일 복구 가능)

GlusterFS의 구성 방식 2 - Distributed Volume 방식

하나의 데이터가 들어오면 n개의 서버 스토리지 중 한 곳에만 저장됩니다. (RAID 0 개념)

(1 x n)

즉, 여러 스토리지를 하나의 저장장치로 보이기 위해 묶는 개념과 동일합니다.

마운트 포인트를 통해 파일을 탐색하면 어떤 서버에 저장되어 있건 Mount 포인트 입장에선 데이터가 존재하는 것으로 보입니다.

즉, 마운트 포인트를 통하지 않고 서버의 Brick 데이터 경로로 직접 접근하면 파일 탐색이 불가능 할 수 있습니다.

(실제 어느 서버에 저장되어 있는지는 일일히 n개의 서버 스토리지에 접근해서 찾아야합니다.)

위 구성의 경우 저장용량에 손실은 없으며 n개를 확장하면 n개의 용량만큼 계속해서 증설되는 특징이 있습니다.

> N개의 서버 중 하나의 서버 스토리지만 장애가 발생해도 모든 서버에서 해당 파일을 탐색 할 수 없게 되어 안정성이 확장 될 수록 계속해서 기하 급수적으로 떨어짐.

GlusterFS의 구성 방식 3 - Distributed Replicated Volume 방식

하나의 데이터가 들어오면 분산 저장 된 노드의  한 곳에만 저장하며, 노드의 Replicated 된 스토리지에 같이 저장합니다.

(n X n)

데이터가 들어오면 분산 저장 된 노드 중 한 곳으로만 들어가고, 그 노드의 복제 처리 된 스토리지에만 복제하여 저장합니다.

위의 예시는 2x2 구성의 예시이며 앞의 2는 분산, 뒤의 2는 복제를 뜻 합니다.

2분산 2복제

=

  2   X   2

분산    복제

만약 2 x 3 예시라면 아래와 같습니다.

 

       = 2분산 3복제

즉 이 경우 가용 가능한 용량의 수식은 다음과 같습니다.

가용한 용량 = 전체 스토리지 용량 / 복제 수  이 됩니다.

분산 시스템은 스토리지 용량에 영향을 미치지 않고 복제 시스템이 몇개가 있는지에 따라서만 용량이 감소되므로 총 스토리지 용량에 복제 스토리기 갯수만 나누면 가용 가능한 용량이 됩니다.

 

 

위와 같은 경우 Mount 포인트를 통해 파일을 제어하지 않을 경우 분산 된 노드의 개수만큼의 확률로 파일 제어가 가능한 단점이 있습니다.

실제 분산 된 노드끼리의 정보는 Brick끼리는 통신하고 있지 않기 때문에 Mount 포인트로 접근해야 메타데이터를 읽어들여오기 때문입니다.

브릭에 직접 접근하여 파일을 컨트롤 하는 것이 지양되는 이유에 대해서는 아래 PPT를 참고바랍니다.