저는 하루 평균 5천만 건의 조회수를 추적하고 있는 웹사이트를 가지고 있으며, 향후 3개월 이내에 일일 조회수는 1억 건을 넘어설 것입니다. GlusterFS v 3.0.0(2010년 1월 17일 현재 최신 패치 포함)을 사용하려고 합니다.
현재 우리는 웹 페이지 트래픽을 처리하기 위해 6개의 Xen-Server 5.5u1 VM(각 호스트에 2개)이 있는 3개의 물리적 호스트가 있는 로드 밸런서 환경으로 업그레이드했습니다. 각 머신에는 6개의 Raid-6 로컬 스토리지 드라이브(7200RPM-SATA)가 있습니다. 우리가 사용했던 오래된 컴퓨터에는 미러링된 SAS 10k 드라이브가 1개 있었습니다.
또한 현재 각 호스트에 하나씩 3개의 브릭으로 GlusterFS를 설정했으며 6개의 VM을 클라이언트로 제공하고 있습니다. 테스트에서는 모든 것이 괜찮아 보였습니다. 그러나 우리가 프로덕션에 들어갔을 때 1,500만 개 이상의 히트에도 트래픽을 처리할 수 있는 I/O가 충분하지 않은 것 같았습니다. 몇 주 전에는 기존 서버에서 최대 2천만 개의 트래픽을 처리할 수 있었습니다.
그러한 애플리케이션에 권장되는 구성이 있습니까? 아니면 우리 규모의 사이트에 대해 gluster.org의 문서에서 명확하지 않은 점을 알아야 합니까?
답변1
쓰기 캐시(?)가 없는 6x7.2krpm 드라이브의 RAID-6은끔찍한쓰기 성능이 너무 나빠서 앱이 건강한 조합을 가지고 있는 경우 읽기 성능에도 실제로 영향을 미칠 만큼 디스크를 정체시킬 수 있습니다. 내 말은 현실적으로 해당 배열에서 80/20 읽기/쓰기 분할에서 250개의 임의 iop이 보고 있다는 뜻입니다. 초당 수백 개의 http 요청을 수행하는 경우 아파치 액세스 로그만큼 사소한 것이 DoS 공격처럼 이를 방해할 것입니다.
가능하다면 raid10으로 다시 실행하십시오. 약간의 원시 공간이 필요하지만 I/O 성능에 큰 영향을 미칩니다. 그리고 RAID 카드에 배터리 지원 쓰기 캐시를 얻을 수 있다면 이는 매우 큰 차이를 만듭니다.
나는 특히 glusterfs에 익숙하지 않지만 모든 분산 파일 시스템은 동일한 기본 문제, 즉 네트워크 대기 시간 + 복잡한 잠금 = 성능 저하, 특히 작은 파일 및 특히 상당한 쓰기 작업 부하에서 발생하는 경향이 있습니다.
느린 디스크 I/O와 느린 파일 시스템으로 인해 이 클러스터 디자인은 작업 부하에 적합하지 않습니다. 서버를 반환하거나 적어도 디스크 하위 시스템을 반환하기에는 너무 늦었나요? 이것이 상당한 수익을 올리는 회사의 기본 플랫폼이라면 실제로 전문가를 고용해야 합니다.
답변2
GlusterFS 트래픽을 어떤 매체로 이동하고 있습니까? 이더넷인 경우 TCP/IP의 오버헤드로 인해 구성이 심각하게 제한됩니다. GlusterFS는 가장 효율적이지 않습니다. 실제로 빛나는 곳은 RDMA입니다. Infiniband 또는 10GigE를 사용하여 이를 달성할 수 있습니다.
또한 모두 동일한 임무를 수행하는 경우 각 물리적 호스트에 2개의 가상 호스트를 배치하기로 결정한 이유가 약간 불분명합니다. 베어메탈에서 실행하고 오버헤드를 피하는 것은 어떨까요?
답변3
어떤 버전의 GlusterF를 사용하고 있나요? GlusterFS 3.0.0은 주요 릴리스이며 작은 파일 성능 향상을 포함하여 많은 개선이 이루어졌습니다.
GlusterFS에는 다양한 워크로드에 맞게 조정할 수 있는 성능 변환기가 많이 있습니다. 예를 들어, 읽기 성능을 높이기 위해 미리 읽기 변환기를 사용하고 쓰기 성능을 위해 나중에 쓰기 변환기를 사용합니다. io-cache는 캐싱에 사용할 수 있는 또 다른 성능 변환기입니다.
귀하의 설정 유형은 무엇입니까? 복제나 배포 또는 둘 다를 사용하고 있습니까? 네트워크 백엔드는 무엇입니까? 병목 현상을 제거하기 위해 기존 서버와 새 서버 간의 네트워크/디스크 IO를 벤치마킹했습니까?
귀하의 볼륨 파일을 당사와 공유할 수 있다면 귀하의 워크로드에 대한 최적의 성능을 위해 구성 파일을 조정하는 데 도움을 드릴 수 있습니다.
참고로 저희는 귀하의 질문에 신속하고 심층적인 답변을 얻을 수 있는 30일 무료 평가판 지원 구독[1]을 제공합니다.
건배, 사치
답변4
설정에 대한 더 많은 통찰력이 없으면(예: 웹 사이트가 정적인지 동적인지, 데이터베이스 트랜잭션이 동일한 스토리지 하위 시스템을 사용하는 서버에서 발생하는지) RAID 6은 일반적으로 쓰기 성능에 좋지 않은 선택입니다. 더 많은 복잡성을 도입하더라도 신경쓰지 마세요. 글러스터를 통해. 잠재적으로 두 세트의 쓰기 스트라이프 변환이 진행 중입니다. 하나는 Gluster 수준에서, 다른 하나는 컨트롤러 수준에서 진행됩니다. 그런 다음 쓰기 캐시가 크고 I/O 활동이 낮은 기간이 아니면 작업 속도를 늦추고 I/O 차단을 유발하는 두 가지 패리티 계산이 있습니다.
RAID 10으로 전환하고 파이버 채널이나 다중 결합 GigE 링크를 사용하여 이를 지원하는 것이 좋습니다.