현재 일부 서버 및 앱을 coreOS 환경으로 마이그레이션 하려고 합니다. 여기서 볼 수있는 문제 중 하나는 coreOS가 컨테이너를 새 시스템으로 옮길 때 Docker 볼륨을 처리하지 않으므로 영구 데이터를 관리하는 것입니다. 일부 연구 결과 , 모든 문제를 해결할 수있는 클러스터 파일 시스템 인 glusterFS 를 발견 했습니다 .
내 현재 아이디어는 다음과 같습니다 /mnt/gluster. 예를 들어 각 coreOS 시스템에서 권한있는 컨테이너로 실행되고 스토리지를 노출하는 glusterFS 컨테이너가 있습니다. 내 Dockerfile모든 볼륨을이 경로에 마운트하도록 지정합니다.
다음으로 고려해야 할 것은 어떤 컨테이너가 자체 볼륨을 얻어야하고 어떤 컨테이너가 공유해야하는지였습니다. 예를 들어, 모든 mysql컨테이너는 자체적으로 복제를 처리 할 수 있으므로 자체 볼륨을 갖게됩니다. 나는 그걸 엉망으로 만들고 싶지 않습니다. 동일한 웹 사이트를 제공하는 웹 서버는 “사용자가 업로드 한 이미지”등과 같은 데이터를 복제 할 수 없으므로 동일한 볼륨을 올바르게 사용합니다.
아무도 이와 같은 것을 시도했거나 내가 놓친 것이 있습니까?
답변
우리는 CoreOS 대신 Atomic ( http://www.projectatomic.io/ )을 사용 하여 유사한 복제 설정을 세 개의 replica-2 세트가있는 복제 된 비 분산 GlusterFS 스토리지 시스템에 배포했습니다. 이것은 매우 잘 작동합니다.
그러나 GlusterFS의 몇 가지 특수한 특성을 염두에 두어야합니다. Brian이 이미 언급했듯이 Gluster는 무엇보다 일관성과 신뢰성을 제공합니다. 더 자주 변경이 발생하면 더 많은 복제가 발생합니다. 이로 인해 시스템에 많은 압력이 가해집니다.
IO 서브 시스템이 빠르거나 (저장소 인 경우) 사용 가능한 가장 빠른 네트워크 연결로 Gluster 노드를 연결하십시오. GBit 만있는 경우 집계하십시오! 마지막으로 스토리지 시스템은 심각한 컴퓨팅 성능을 발휘해야하며 Gluster는 상태를 확인하기 위해 많은 계산을 수행합니다. 즉, 고부하에서도 Gluster가 제공합니다.
MySQL 전략을 재고하십시오. Gluster는 복제 기능을 제공하며로드 균형 조정 기능도 제공합니다. 실제로 Gluster를 사용하는 것이 더 빠를 수 있습니다.
답변
glusterfs의 사용은 사용중인 스토리지 백엔드에 따라 다릅니다. 클러스터 파일 시스템으로서 물리적 스토리지를 클러스터링하여 하나의 큰 연속 볼륨으로 나타납니다. 이 공식 빠른 시작 안내서 에는 프로세스에 대한 좋은 설명이 있습니다.
설정에서 둘 이상의 개별 백엔드 스토리지 서버 또는 모든 도커 볼륨을 저장하기 위해 유사한 것을 사용하는 경우 glusterfs 또는 다른 유사한 병렬 파일 시스템을 사용하면 상당한 성능 이점을 제공 할 수 있습니다. 이 경우 HPC 커뮤니티에서 병렬 파일 시스템으로 널리 사용되는 Luster 사용을 고려할 수도 있습니다 .
병렬 / 클러스터 파일 시스템의 조정, 디버깅 및 구성은 많은 전문 지식, 인내심 및 때로는 처음부터 다시 시작하려는 의지를 필요로하는 시간 소모적 인 작업이 될 수 있습니다. 병렬 파일 시스템이 제공하는 성능 이점이이를 설정하고 유지 관리하는 데 필요한 노력의 가치가 있는지 확인하는 것이 신중해야합니다.