성능상의 이유로, 여러개의 디스크에 'stripe' 로 자료를 분산해두는 것이 가능 하다. 이것은 블럭 1이 물리적 볼륨 A 에, 블럭 2가 물리적 볼륨 B 에 있고, 다시 블럭 3이 물리적 볼륨 A 에 있음을 의미한다. 또한 2개 이상의 디스크에 스트라이 프 할 수도 있다.
이러한 배열은 더 많은 디스크 대역폭을 이용가능함을 의미한다. 또한 보다 많은 'spindles' 가 포함된다. 뒤에서 더 자세히 다루겠다.
성능을 향상시킬 뿐 아니라, 자료의 사본을 여러개의 디스크에 보관하는 것도 가능 하다. 이것은 미러링(mirroring) 이라고 불린다. 현재, LVM 자체에서는 이것을 지원하지 않지만, 미러링을 할 수 있는 방법은 있다.
디스크 성능은 적어도 세가지 요소에 의해 영향을 받는다. 가장 명백한 것은 디스크에서 자료가 순차적으로 읽혀지거나 쓰여지는 속도이다. 이것은 SCSI/IDE 버스에서 그것에 물려있는 단일 디스크에서 파일을 읽거나 쓸때 제한 요소이다.
그 후에는 디스크로 이용가능한 대역폭이 있다. 한개의 SCSI 버스에 7개의 디스크 가 있다면, 이것은 디스크 자체의 쓰기 속도보다 작을수도 있다. 만약 충분한 메모리를 사용한다면, 이러한 병목점이 문제가 되는것을 막을수도 있다.
그리고 레이턴시도 있다. as the saying goes, 레이턴시는 언제나 나쁜 소식이다. 그리고 더 안좋은 것은, 레이턴시를 낮추기 위해서는 더 많은 돈을 쓸 수도 없다 는 것이다. 오늘날 대부분의 디스크들은 7ms 정도의 레이턴시를 갖는 것으로 보인 다. 그 뒤에는 SCSI 레이턴시도 있는데, 25ms 정도가 된다.
FIXME: 최근의 수치들이 필요하다!
이것은 무엇을 의미할까? 합쳐진 레이턴시가 전형적인 경우엔 30ms 근방이 될 것이라는 것이다. 그래서 초당 33 번 정도의 디스크 작업만을 수행할 수 밖에 없다. 만약 초당 수천번 이상의 쿼리를 할 수 있기를 원하지만, 거대한 캐쉬를 갖고 있지 못할 경우라면, 당신은 매우 운이 없는 것이다.
만약 병렬로 동작하는 여러개의 디스크나, 'spindles' 를 갖고 있다면, 동시에 여러개의 명령어를 실행시킬 수 있는데, 이것은 훌륭하게 레이턴시 문제를 피해가는 방법이다. 어떤 어플리케이션들은, 거대한 뉴스 서버와 같은 것들은, 스트라이핑이나 다른 IO 현명함(smartness) 없이는 더이상 동작할 수 없다.
이것이 스트라이핑이 하는 것이다. 만약 당신의 버스가 그것에 도달한다면 (if your bus is up to it), 순차적인 읽기와 쓰기조차도 빨라질 수 있다.
추가의 방법이 수반되지 않는 스트라이핑은 실패 확률을, '비트 당'으로 증가 시킨다. 만약 당신의 디스크중 어떤 것이라도 고장난다면, 전체의 논리적 볼륨이 사라져버린다. 만약 단순히 데이터를 연결하기(concatenate)만 한다면, 파일 시스템의 일부분만을 잃게 될 것이다.
궁극의 선택은 미러되는 스트라이프이다.
FIXME: 미러되는 스트라이프를 LVM 과 md 로 만들라
스트라이프 설정을 지정하는 것은 lvcreate 로 논리적 볼륨을 생성할때 완료된다. 그중에는 두가지 관련있는 파라미터가 있다. -i 를 이용해 LVM 이 얼마나 많은 물리적 볼륨을 분산시켜 사용해야 하는지를 지시할 수 있다. 스트라이핑은 실제로 bit-by-bit 기반으로 행해지지는 않으며, 블럭상에서 일어난다. -I 로는 킬로바이트 단위로 설정할 수 있다. 이것은 2의 거듭제곱 형태가 되어야 함과, 가장 조잡한 뭉치회는 128Kbyte 임을 유의하라.
예제:
# lvcreate -n stripedlv -i 2 -I 64 mygroup -L 20M lvcreate -- rounding 20480 KB to stripe boundary size 24576 KB / 6 PE lvcreate -- doing automatic backup of "mygroup" lvcreate -- logical volume "/dev/mygroup/stripedlv" successfully created |
만약 같은 디스크에서 2개 이상의 파티션에 대해 스트라이프를 한다면, 성능 '이득' 은 음이 될 수도 있다 - 그렇게 하지 않도록 유의하라. 하나의 IDE 버스에 연결된 두개의 디스크로 스트라이핑을 하는 것 역시 쓸모없는 것으로 보인다 - 내가 기억 하는 것 이상으로 IDE 가 발전해오지 않은 한은 그렇다.
FIXME: 지금도 여전히 그럴까?
오래된 마더보드들은 두개의 IDE 버스를 갖고 있을 것인데, 두번째 버스는 느린 씨디롬 드라이브를 사용하는데 할당되었을 것이다. 여러가지의 툴을 이용해서 벤치마크를 수행할 수 있는데, 가장 주목할만한 것은 'Bonnie' 이다. ReiseFS 개발자들은 Bonnie++ 를 발표했는데 성능 자료를 측정하기 위해 사용할 수 있다.
많은 하이엔드 인텔 x86 서버들은 하드웨어 RAID 컨트롤러를 갖고 있다. 그것들의 대부분은 적어도 2개의 독립적인 SCSI 채널을 갖고 있다. 다행히도, 이것들은 LVM 에 거의 관계가 없다. Linux 가 그러한 컨트롤러에 관한 것을 알 수 있기 전에 관리자는 raid 컨트롤러 자체 안에서 논리적 드라이브를 결정해야 한다. 예를 들어 [ SCSI 채널 A에 있는 두개의 디스크를 스트라이프로 묶어서, 채널 B 에 있는 두개의 디스크에 그것들을 미러할 수 있다. 이것은 전형적인 성능과 데이터 안정성 을 최대화하는 전형적인 레이드 0/1 설정이다. 이렇게 설정된 시스템에서 리눅스가 부팅될 때 리눅스는 레이드 컨트롤러에 있는 오직 하나의 디스크만을 '볼' 수 있으 며, 이 디스크는 레이드 0/1 스트라이프셋에서 네개의 디스크를 포함하고 있는 논리적 드라이브이다. 이것은, LVM 에 관련해서는, 머신에 오직 하나의 디스크만 존재하며, LVM 에서도 역시 그렇게 사용됨을 의미한다. 만약 디스크중의 하나가 고장 나더라도, LVM 은 알지도 못할 것이다. 관리자가 디스크를 교체할 때(심지어 핫스왑 하드웨어를 가진 것을 즉시(on the fly) 교체하더라도), LVM 은 그것을 알지 못할 것이고, 컨트롤러가 미러된 자료를 재동기화(resync) 하고, 모든것이 좋은 상태로 돌아올 것이다. 이것은 대부분의 사람들이 한걸음 뒤로 물러서서 "그렇다면 이 레이드 컨트롤러를 이용하여 LVM 이 나에게 어떤 도움이 될까요?" 라고 물어보는 것이다. 간단한 답변은, 대부분의 경우에, 당신이 레이드 컨트롤러에서 논리적 드라이브를 정의한 이후에는, 더 이상의 디스크를 그 드라이브에 추가할 수 없다는 것이다. 그래서 만약 당신이 공간 요구량을 잘못 계산하거나 단지 더 많은 공간을 추가로 필요로 할 뿐이라면, 이미 존재하는 스트라이프셋에 새로운 디스크나 디스크의 집합 을 추가할 수 없다. 이것은 당신이 컨트롤러에서 새로운 레이드 스트라이프셋을 생성 해야 하고, 그 후에는 LVM 을 이용해서 단순히 LVM 논리 볼륨을 확장할 수 있으며, 따라서 빈틈없이 레이드 컨트롤러에 있는 두개의 스트라이프셋을 모두 확장하는 것을 의미한다.
FIXME: 이 주제에 대해 더 많은것이 필요한가?
리눅스 2.4에는 매우 훌륭한 레이드가 있다. 리눅스 2.2에서는 기본값으로, Alan Cox 에 의해 릴리즈 된 것에는, 잘 고려되지 않는 이전의 레이드 버전을 특징이다. 2.2 가 여전히 오래된 릴리즈를 특징으로 삼고 있는 이유는 커널 개발자들이 안정버전에서 사용자영역(userland) 업데이트를 필요로 하는 변화를 원하지 않기 때문이다.
Red Hat, Madrake, SuSE 를 포함한 대부분의 사람들은, 그것을 훨씬 좋아보이는 0.90 버전으로 교체하기로 결정했다.
우리는 여기서 오직 0.90 버전만을 다룰 것이다.
FIXME: 이것에 대해 더 많이 써야 한다