사례 연구: CEPH 파일 시스템
Ceph는 연결된 디스크가 있는 대규모 서버 클러스터에 배포할 수 있는 스토리지 시스템입니다. 다음 비디오는 Ceph의 기본 개념을 설명합니다.
Ceph의 디자인 목표2에는 다음이 포함됩니다.
- 광범위한 애플리케이션을 유연하게 지원하는 범용 스토리지 클러스터
- 수백 개의 노드 및 페타바이트 스토리지로 원활하게 확장할 수 있는 아키텍처
- 자체적으로 관리하고 강력하며, 단일 실패 지점이 없는 매우 안정적인 시스템
- 즉시 사용 가능한 상용 하드웨어에서 실행할 수 있어야 하며, 다음의 그림처럼 세 가지 다른 추상화를 통해 액세스할 수 있도록 설계된 시스템
Ceph 스토리지 클러스터는 분산 개체 저장소입니다. 스토리지 클러스터의 위에 계층화되어 클라이언트 지향 스토리지 서비스와는 다릅니다. Ceph 개체 게이트웨이 서비스를 사용하면 클라이언트에서 Amazon의 S3 및 OpenStack의 Swift 프로토콜과 현재 호환되는 REST 기반 HTTP 인터페이스를 사용하여 Ceph 스토리지 클러스터에 액세스할 수 있습니다. Ceph 블록 디바이스 서비스를 사용하면 클라이언트에서 스토리지 클러스터를 블록 디바이스로서 액세스할 수 있으며, 이 디바이스는 로컬 파일 시스템으로 포맷하고 운영 체제에 탑재하거나 Xen, KVM, VMWare 또는 QEMU에서 가상 머신을 작동하는 가상 디스크로 사용할 수 있습니다. 마지막으로 Ceph FS(Ceph 파일 시스템)는 전체 스토리지 클러스터에 걸친 파일 및 디렉터리 추상화를 POSIX 규격 파일 시스템으로서 제공합니다.
그림 6: Ceph 에코시스템
아래 그림은 Ceph의 아키텍처를 자세히 나타냅니다.
그림 7: Ceph 아키텍처
Ceph의 핵심은 RADOS라는 분산 개체 스토리지 시스템입니다. 클라이언트에서는 소켓 기반이며 다양한 프로그래밍 언어를 지원하는 librados라는 낮은 수준의 API를 사용하여 직접 RADOS와 상호 작용할 수 있습니다. 또한 클라이언트에서 3개의 개별 추상화를 RADOS에 제공하는 더 높은 수준의 API 3개와 상호 작용할 수도 있습니다.
RADOS Gateway, 즉 radosgw를 사용하면 클라이언트에서 HTTP에서 REST 기반 게이트웨이를 통해 RADOS에 액세스할 수 있습니다. 이는 Amazon S3 개체 서비스를 에뮬레이트하며 Amazon S3 API 또는 OpenStack SWIFT API를 사용하는 애플리케이션과 호환됩니다.
RADOS Block Device, 즉 RBD는 SAN과 매우 유사한 범용 분산 블록 디바이스로 RADOS 개체 저장소를 노출합니다. RBD를 사용하여 RADOS에서 블록 디바이스를 만들어내고 커널 드라이버를 사용하여 Linux 시스템에 탑재할 수 있습니다. RBD는 Xen, VMWare, KVM 및 QEMU와 같은 인기 있는 가상화 시스템의 가상 디스크 이미지로도 사용할 수 있습니다.
Ceph FS는 RADOS에 계층화된 POSIX 규격 분산 파일 시스템으로 Linux 클라이언트의 파일 시스템 내에서 직접 탑재할 수 있습니다. Ceph FS는 이 페이지 뒷부분에서 자세히 설명합니다.
Ceph 스토리지 클러스터 아키텍처(RADOS)
Ceph의 핵심은 RADOS(Reliable, Autonomous, Distributed Object Store)입니다. RADOS에서 데이터는 머신의 클러스터에 분산된 개체로 저장됩니다. 클라이언트에 개체를 저장하고 검색하여 RADOS 클러스터와 상호 작용합니다. 개체는 개체 이름(개체를 파악하는 데 사용되는 키) 및 개체의 이진 콘텐츠(특정 개체 키와 연결된 값)로 구성됩니다. RADOS의 역할은 확장 가능하고 안정적이며 내결함성이 있는 방식으로 클러스터에 분산된 방식을 사용해 개체를 저장하는 것입니다.
RADOS 클러스터에는 두 가지 유형의 노드, 즉 OSD(개체 스토리지 디먼) 및 모니터 노드가 있습니다(그림 8). OSD는 개체를 저장하고 개체에 대한 요청에 응답합니다. OSD는 각 노드에서 로컬 파일 시스템을 사용하여 노드에 이러한 개체를 저장하고 버퍼 캐시를 유지하여 성능을 향상합니다. 모니터 노드는 클러스터의 상태를 감시하여 클러스터에 입장하고 나가는 OSD를 계속 추적합니다.
그림 8: RADOS 아키텍처. OSD는 노드의 데이터를 담당합니다(일반적으로 물리적 디스크당 하나의 OSD가 배포됨). M으로 표시된 노드는 모니터 노드입니다.
RADOS의 클러스터 상태 및 모니터
RADOS 클러스터의 상태는 클러스터의 모든 노드에서 공유하는 클러스터 맵이라는 개체에 캡슐화됩니다. 클러스터 맵에는 현재 존재하는 OSD 수, OSD에 데이터가 분산된 방식(다음 섹션에서 자세히 설명)에 관한 간략한 표현, 클러스터 맵이 빌드된 시간을 나타내는 논리적 타임스탬프를 비롯하여 지정된 순간의 클러스터 상태에 대한 정보가 포함됩니다. 클러스터 맵에 대한 업데이트는 모니터 노드에 의해 피어 투 피어 증분 방식으로 수행됩니다. 즉, 클러스터 맵 내의 한 타임스탬프에서 다른 타임스탬프로 이동하는 변경 내용만 한 클러스터 안의 노드 간에 전송되어 노드 간에 전송되는 데이터의 양을 작게 유지합니다.
RADOS의 모니터는 OSD의 상태가 변경되는 경우 클러스터 맵의 마스터 복사본을 저장하고 주기적 업데이트를 전송하여 스토리지 시스템 관리를 전체적으로 담당합니다. 모니터는 paxos 알고리즘을 기반으로 구성되며 대부분의 모니터에서 클러스터 맵을 읽거나 업데이트해야 합니다. 모니터는 맵 업데이트가 직렬화되고 일관적인지 확인합니다. RADOS 클러스터는 3개 미만의 적은 수의 모니터를 갖도록 설계되었으며 일반적으로 홀수이므로 개별 모니터가 서로 합의를 해야 하는 경우에 연결이 끊어지지 않도록 해줍니다.
RADOS의 데이터 배치
분산 개체 스토리지가 제대로 작동하려면 클라이언트에서 올바른 OSD에 연결하여 개체와 상호 작용해야 합니다. 먼저 클라이언트는 모니터에 연결하여 주어진 스토리지 클러스터에 대한 클러스터 맵을 검색합니다. 클러스터 맵에 포함된 정보는 클러스터의 특정 개체를 담당하는 정확한 OSD를 결정하는 데 사용할 수 있습니다.
첫 번째 단계는 특정 개체의 배치 그룹을 결정하는 것입니다(그림 9). 배치 그룹은 개체가 있는 버킷이라고 생각할 수 있습니다. 이 작업은 해시 함수를 사용하여 수행됩니다(사용할 최신 해시 함수는 항상 클러스터 맵에서 가져옴). 지정된 개체에 대한 배치 그룹을 결정한 후에는 클라이언트에서 해당 배치 그룹을 담당하는 OSD를 찾아야 합니다.
그림 9: CRUSH 알고리즘을 사용하여 배치 그룹에 대한 개체를 찾고 마지막으로 OSD에 대한 개체 찾기
OSD에 배치 그룹을 할당하는 데 사용하는 알고리즘은 CRUSH(Controlled Replication Under Scalable Hashing)1 알고리즘이라고 합니다(그림 9). CRUSH는 의사 난수이지만 결정적 방식으로 클러스터 전체에 배치 그룹을 할당합니다. CRUSH는 OSD에서 클러스터를 들어가거나 나갈 때 CRUSH가 대부분의 배치 그룹 위치를 유지하고 적은 양의 데이터만 이동하여 균형 분포를 유지하기 때문에 해시 함수보다 더 안정적입니다. 반면에 간단한 해시 함수는 버킷이 추가되거나 제거될 때 대부분의 키를 재배포해야 합니다. CRUSH 알고리즘에 대한 전체 설명은 이 논의의 범위를 벗어납니다. 관심이 있는 사용자는 CRUSH: Controlled, scalable, decentralized placement of replicated data를 참조하세요.
개체 이름이 배치 그룹에 해시되면 CRUSH가 배치 그룹을 담당하는 정확한 r개의 OSD 목록을 생성합니다. 여기서 r은 지정된 개체에 대한 복제본 수입니다. 클러스터 맵의 정보에 따라 이 매핑에 포함된 활성 OSD를 파악한 다음, 지정된 개체를 사용하여 상호 작용(예: 만들기, 읽기, 업데이트, 삭제 등의 작업)을 하기 위해 OSD에 연결할 수 있습니다.
RADOS의 복제
RADOS에서 개체는 해당 개체의 배치 그룹과 연결된 여러 OSD 간에 복제됩니다. 이렇게 하면 특정 OSD에 오류가 생겨도 특정 개체의 복사본이 여러 개 확보됩니다. RADOS에는 복제를 실제로 수행하는 데 사용 가능한 여러 스키마가 있습니다. 즉, 기본 복사본, 체인 및 splay 복제 스키마입니다(그림 10).
그림 10: RADOS에서 지원되는 복제 모드 (출처: 2)
기본 복사본 복제: 기본 복사본 복제 스키마에서 클라이언트는 개체와 상호 작용하기 위해 사용 가능한 첫 번째 OSD(기본 복제본 OSD)와 상호 작용합니다. 기본 복제본 OSD에서 요청을 처리하고 클라이언트에 다시 응답합니다. 쓰기의 경우 기본 복제본 OSD는 r-1개의 복제본에 대한 쓰기 요청을 전달하여 개체의 로컬 복사본을 업데이트하고 마스터에 응답합니다. 해당 개체에 대한 다른 OSD가 모든 쓰기 작업을 커밋할 때까지 마스터의 쓰기 작업은 지연됩니다. 그런 다음, 마스터는 클라이언트에 대한 쓰기를 승인합니다. 모든 복제본이 기본 복사본 OSD에 응답할 때까지 쓰기는 완료되지 않습니다. 동일한 프로세스가 읽기에 적용되는 경우, 기본 복사본은 모든 복제본에 연결되고 개체 값이 모든 복제본에서 동일한 경우에만 읽기에 응답합니다.
체인 복제: 개체에 대한 요청은 r번째(최종) 복제본이 발견될 때까지 체인으로 전달됩니다. 작업이 쓰기 작업인 경우 마지막 복제본에 가는 도중 각 복제본에 커밋됩니다. 최종 복제본이 포함된 최종 OSD는 마지막으로 클라이언트에 대한 쓰기를 승인합니다. 모든 읽기 작업은 클러스터에서 데이터를 읽는 데 필요한 홉의 수를 줄이기 위해 테일로 바로 전달됩니다.
Splay 복제: Splay 복제는 기본 복사본 복제와 체인 복제의 요소를 결합합니다. 읽기 요청은 복제본 체인의 마지막 OSD로 전달되지만 쓰기는 먼저 헤드로 보내집니다. 체인과 달리 중간 OSD에 대한 업데이트는 기본 복사본 복제 스키마와 유사하게 병렬로 수행됩니다.
이러한 복제 스키마 외에도 RADOS의 지속성은 별도의 두 승인 메시지를 활용하여 처리됩니다(그림 11). 각 OSD에는 대상이 되는 데이터의 버퍼 캐시가 있습니다. 업데이트는 버퍼 캐시에 기록되고 ack 메시지를 통해 즉시 다시 승인됩니다. 이 버퍼 캐시는 주기적으로 디스크에 플러시되고, 마지막 복제본이 데이터를 디스크에 커밋한 경우 커밋 메시지가 클라이언트에 전송되어 데이터가 지속되었음을 나타냅니다.
그림 11: RADOS에서 확인 메시지와 커밋 메시지 비교(출처: 2)
RADOS의 일관성 모델
RADOS의 모든 메시지(클라이언트 및 노드 간 피어 투 피어 메시지 모두)에는 메시지의 순서를 지정하고 일관된 방식으로 적용하기 위해 타임스탬프로 태그가 지정됩니다. 메시지 요청자의 오래된 클러스터 맵으로 인해 OSD에서 잘못된 메시지를 탐지하는 경우 메시지 요청자를 최신 상태로 만들기 위해 증분 맵 업데이트를 보냅니다.
RADOS에서 제공하는 엄격한 일관성 보장을 신중하게 처리해야 하는 코너 케이스가 있습니다. 특정 OSD에 대한 배치 그룹 매핑이 변경될 경우(클러스터 맵이 변경되는 경우) 시스템은 이전 OSD와 새 OSD 사이에 배치 그룹의 인계가 원활하고 일관된 방식으로 수행되도록 해야 합니다. 배치 그룹을 변경하는 동안 새 OSD는 상태 인계를 위해 이전 OSD에 연결해야 하며, 그동안에 이전 OSD는 변경 내용을 알게 되어 특정 배치 그룹을 위한 쿼리 응답을 중지합니다.
엄격한 일관성을 보장하기 어려울 수 있는 또 다른 경우는 네트워크 오류가 발생하여 네트워크 파티션을 유발하는 경우입니다. 이 경우 이전 클러스터 맵이 있는 일부 클라이언트는 해당 OSD에서 읽기 작업을 계속 수행할 수 있는 반면 업데이트된 맵은 해당 배치 그룹을 담당하는 OSD를 변경할 수 있습니다. 이는 이전에 CAP 정리에 대한 논의에서 강조했던 오류 시나리오임을 기억하실 것입니다. 이 경우에는 이 불일치 기간이 항상 존재합니다. RADOS는 기본 간격인 2초마다 다른 복제본의 하트비트를 OSD에 요구하여 이 시나리오의 영향을 완화합니다. 특정 OSD가 특정 임계값의 다른 복제 그룹에 도달할 수 없는 경우 읽기를 차단합니다. 또한 특정 배치 그룹의 새 기본 복제본으로 할당된 OSD는 이전 배치 그룹 기본에서 인계 승인을 받거나 이전 배치 그룹의 기본 복제본이 다운된 것으로 가정하기 위한 하트비트 간격을 기다려야 합니다. 이러한 방식으로 네트워크 파티션이 있는 RADOS 클러스터의 잠재적 불일치 기간이 줄어듭니다.
RADOS의 오류 검색 및 내결함성
RADOS의 노드 오류는 배치 그룹에 할당된 OSD와 OSD 및 모니터 노드 간의 통신 오류 중에 검색됩니다. 제한된 횟수의 다시 연결 시도 내에서 노드가 응답하지 못하면 중지로 선언됩니다. 배치 그룹의 일부인 OSD는 오류가 검색되도록 하트비트 메시지를 교환합니다. 이로 인해 모니터 노드가 클러스터 맵을 업데이트하고 증분 맵 업데이트 메시지를 통해 모든 노드에 알리는 과정을 주도적으로 수행하게 됩니다. 클러스터 맵의 업데이트 후 OSD는 각 배치 그룹에 대해 원하는 복제본 수를 유지하기 위해 개체를 교환합니다. OSD에서 중지로 선언된 메시지를 검색하는 경우에는 해당 버퍼를 디스크에 동기화하고 동작이 일관되도록 스스로 종료합니다.
Ceph 파일 시스템
위의 그림에 나와 있는 것처럼 Ceph FS는 RADOS 스토리지 시스템에 대한 추상화 계층입니다. RADOS에는 개체 이름 이외의 개체에 대한 다른 메타데이터 개념이 없습니다. Ceph 파일 시스템에서는 RADOS에 저장된 개별 파일 개체를 기반으로 파일 메타데이터를 계층화할 수 있습니다. 다음 비디오는 CephFS의 개념을 설명합니다.
Ceph FS는 OSD 및 모니터의 클러스터 노드 역할 외에 MDS(메타데이터 서버)를 소개합니다(그림 12). 이러한 서버에는 파일 시스템 메타데이터(디렉터리 트리와 각 파일에 대한 액세스 제어 목록 및 권한, 모드, 소유권 정보 및 타임 스탬프)가 저장됩니다.
그림 12: Ceph 파일 시스템의 메타데이터 서버
Ceph FS에서 사용하는 메타데이터는 여러 가지 면에서 로컬 파일 시스템에서 사용하는 메타데이터와 다릅니다. 로컬 파일 시스템에서 파일은 파일의 데이터 블록을 가리키는 포인터 목록을 포함하는 inode에 의해 설명된다는 것을 기억하실 것입니다. 로컬 파일 시스템의 디렉터리는 다른 디렉터리나 파일 등 다른 inode에 대한 링크가 있는 특수 파일입니다. Ceph FS에서 메타데이터 서버의 디렉터리 개체에는 그 내부에 포함된 모든 inode가 포함됩니다.
동적 하위 트리 분할
처음에는 단일 메타데이터 서버에서 클러스터에 대한 전체 메타데이터를 담당합니다. 메타데이터 서버가 클러스터에 추가되면 파일 시스템의 디렉터리 트리가 분할되고 결과 메타데이터 서버 그룹에 할당됩니다(그림 13). 각 MDS는 카운터를 사용하여 해당 디렉터리 계층 구조 내에서 메타데이터의 인기도를 측정합니다. 가중치가 적용된 스키마3는 디렉터리에 있는 특정 리프 노드의 카운터를 업데이트하는 데뿐만 아니라 해당 디렉터리 요소의 상위 항목에 대한 루트까지 업데이트하는 데에도 사용됩니다. 따라서 각 MDS는 클러스터에 추가될 때 새 MDS로 이동할 수 있는 메타데이터의 핫스팟 목록을 보관할 수 있습니다.
그림 13: Ceph 파일 시스템의 동적 하위 트리 분할
메타데이터 서버의 캐싱 및 내결함성
Ceph FS의 메타데이터 서버는 일반적으로 메모리에서 메타데이터 정보를 캐시하고 메모리 외부의 요청 대부분을 처리합니다. 또한 MDS 서버는 업데이트를 RADOS으로 다운스트림에 전송하는 저널링의 형태를 사용하며, 이러한 데이터는 메타데이터 서버마다 작성됩니다. 메타데이터 서버에 오류가 발생하는 경우 저널을 재생하여 새 MDS 또는 기존 MDS에서 실패한 MDS 서버의 트리 부분을 다시 빌드할 수 있습니다.
참조
- Weil, S. A., Brandt, S. A., Miller, E. L., & Maltzahn, C. (2006). CRUSH: Controlled, scalable, decentralized placement of replicated data 슈퍼 컴퓨팅에 관한 2006년 ACM/IEEE 컨퍼런스 회의록 122
- Weil, S. A., Brandt, S. A., Miller, E. L., & Maltzahn, C. (2006). Ceph: A scalable, high-performance distributed file system OSDI(운영 체제 디자인 및 구현)에 관한 제 7회 심포지엄 회의록 307~320
- Weil, S. A., Pollack, K. T., Brandt, S. A., & Miller, E. L. (2004). Dynamic metadata management for petabyte-scale file systems 슈퍼 컴퓨팅에 관한 2004년 ACM/IEEE 컨퍼런스 회의록 4