FlashCache로 IO 개선


14

RAID 1 (SW-RAID)에서 실행중인 HDD 2 개 (2x 1TB)의 서버가 있습니다. 을 사용하여 IO 성능을 향상시키고 싶습니다 flashcache. 를 사용하여 실행중인 KVM 가상 머신이 있습니다 LVM.

이와 관련하여 다음 질문이 있습니다.

  • 이것도 효과가 있을까요? flashcache블록 장치에서 작동하지만 이들은 자체 설정이있는 모든 가상 머신입니다.
  • 성능을 얼마나 높일 수 있습니까? 대부분의 가상 머신은 웹 사이트 및 일부 호스트 게임을 실행합니다.
  • SSD는 얼마나 커야합니까? 더 많은 파일을 캐시 할 수 있기 때문에 SSD가 클수록 성능이 향상됩니까?
  • SSD가 죽으면 어떻게됩니까? 시겠습니까 flashcache기존의 HDD에서 파일을 검색하고 나는 단순히 SSD를 대체 할 수 있을까?
  • 얼마나 빠른 것 writeback에 비해 수 writethroughwritearound?

불행히도 테스트 시스템에 액세스 할 수 없으므로 flashcache디스크를 마운트 해제하지 않고 라이브 서버에 설치할 수 있습니까? 여기서 사용할 훌륭한 자습서를 찾았습니다 .


SSD를 기본 드라이브로 사용할 수 있다면보다 일관된 성능을 누릴 수 있다고 생각합니다.
ewwhite

테스트 시스템에 액세스 할 수 없습니까? HDD가있는 워크 스테이션, SSD 및 두 개의 가상 디스크가있는 가상 머신 (각 장치에 하나씩 있음) 만 있으면됩니다. 프로덕션 시스템은 학습 실험실로 사용되지 않습니다.
Skyhawk

당신이 언급 한 튜토리얼에서 링크가 죽었습니다. 그 정보를 찾을 수있는 다른 곳이 있습니까?
Thaeli

답변:


18

이전에 보지 못한 사람들을 위해 Flashcache는 SSD 드라이브로 Linux 블록 캐시를 확장하는 방법입니다. 캐싱을 위해 RAM이 반 TB 인 서버를 실행하는 것보다 저렴합니다.

이것도 효과가 있을까요?

그렇습니다. Linux 블록 캐시는 파일이 아닌 액세스 된 블록 을 캐싱하여 작동 합니다 . KVM 시스템에 블록 장치에 직접 액세스하지 않는 한 (그렇지 않은 경우) Linux 블록 캐시가 작동합니다. 당신이 경우, 하는 대답 KVM 기계를 직접 블록 장치 액세스를 제공 불분명하다.

파일 백업 가상 디스크를 사용하는 경우 확실히 작동합니다.

LV 지원 가상 디스크를 사용하고 있다면 잘 모르겠습니다.

성능을 얼마나 높일 수 있습니까?

그것은 우리가 대답 할 수없는 것입니다. 그것은 다양한 것들에 달려 있습니다. 요약하면, SSD 크기를 활성 블록 세트보다 크게 만드는 최상의 성능을 얻을 수 있습니다. 완벽한 캐싱을 얻는 경우 성능은 SSD에서 전체 시스템을 실행하는 것과 비슷합니다. 당신이 효과적으로 할 것입니다.

SSD는 얼마나 커야합니까?

필요한 정확한 크기를 찾는 것은 우리가 도울 수없는 일입니다. 캐시 -SSD와 기본 스토리지 간의 정확한 비율을 찾는 것은 간단한 문제가 아닙니다.

이 작업을 복잡하게하면 특정 파일 시스템 작업 및 일부 데이터베이스 구성과 같이 즉시 플러시하도록 설정된 쓰기가 이루어집니다. 이러한 쓰기는 잠깐 동안 만 캐시되며 플래시 캐쉬 유무의 영향을받지 않습니다.

SSD가 죽으면 어떻게됩니까?

Linux에 드롭 캐시를 지시하지만 트위스트를 지정할 때도 마찬가지입니다. 드롭 캐시를 사용하면 블록 캐시에있는 모든 쓰기가 디스크로 플러시됩니다. SSD가 사라질 때 발생하는 현상은 캐싱 모드 에 따라 다릅니다 .

Writethrough : 모든 쓰기가 캐시 및 기본 스토리지에 병렬로 작성되므로 SSD의 갑작스런 손실로 VM에 오류가 발생할 가능성이 매우 적습니다.

Writearound : 모든 쓰기는 기본 스토리지에 작성되며 읽을 때만 캐시됩니다. VM에서 오류가 발생하지 않습니다.

쓰기 저장 : 모든 쓰기는 먼저 캐시에 저장되며 백그라운드에서 기본 스토리지에 기록됩니다. SSD에 장애가 발생할 경우 VM에서 오류가 발생할 가능성이 가장 높으며 프로덕션 환경에서는이 모드를 사용하지 않습니다.

쓰기 및 쓰기와 비교하여 쓰기 속도가 얼마나 빠릅니까?

글을 얼마나 쓰느냐에 따라 다릅니다. 쓰기가 기본 스토리지를 주기적으로 포화시키는 경우 성능이 크게 향상 될 수 있습니다. 대부분의 글을 읽은 경우 개선이 눈에 띄지 않을 것입니다.

또한, 쓰기 저장은 사용중인 작업에 대한 잘못된 정책이므로 사용하지 마십시오.


1
귀하의 종합적인 답변에 감사드립니다. writebackBBU가 없으면 모든 것을 손상시킬 수 있으므로 사용하지 않을 것 입니다. 결국 SSD 캐싱을 사용하지 않을 것이며 결국에는 일반 SSD 만 사용합니다. 다시 감사합니다!
Devator

4

예, 올바른 블록 장치를 사용하는 한 제대로 작동합니다. 그리고 속임수가 있습니다.

LVM은 PV를 검색 할 때 실제 하드 드라이브 자체와 플래시 캐시 "가상"장치를 통해 파티션을 확인해야합니다.

명백한 한 가지 증상은 LVM 도구가 중복 PV에 대해 불평한다는 것입니다.

이러한 경고를 피하고보다 중요한 것은 LVM2에서 플래시 캐시 장치를 사용하도록 필터를 수정하는 것입니다 /etc/lvm/lvm.conf.

LVM.CONF(5)맨 페이지 나보다 더 잘 설명하지만, 만약 내가, 예를 들어 당신을 떠날거야 모든 물리적 볼륨이 flashcache에 의해 백업됩니다 :

filter = [ "a/.*dm.*/" ]


1

일부 응용 프로그램은 버퍼되지 않은 방식으로 파일을 엽니 다.

http://man7.org/linux/man-pages/man2/open.2.html

O_DIRECT (Linux 2.4.10부터)이 파일에 대한 I / O의 캐시 효과를 최소화하십시오. 일반적으로 이는 성능을 저하 시키지만 응용 프로그램이 자체 캐싱을 수행하는 경우와 같은 특수 상황에서 유용합니다. 파일 I / O는 사용자 공간 버퍼에서 직접 또는 사용자 공간 버퍼로 수행됩니다. O_DIRECT 플래그 자체는 데이터를 동 기적으로 전송하려고하지만 데이터 및 필요한 메타 데이터가 전송된다는 O_SYNC 플래그를 보장하지는 않습니다. 동기 I / O를 보장하려면 O_DIRECT 외에 O_SYNC를 사용해야합니다. 자세한 내용은 아래 참고를 참조하십시오.

예를 들어, 이것은 데이터베이스에 매우 일반적입니다. 따라서 Flashcache가이 애플리케이션 세트에서 작동하는지 다시 확인하십시오.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.