처리량
bsr 성능의 처리량 관련 최적화에 대해서 다룹니다. 최적화에 관한 몇 가지 하드웨어 고려 사항과 각각의 세부 튜닝 항목들을 검토하겠습니다.
하드웨어
bsr의 처리능력은 시스템 내의 하위 I/O 서브시스템(디스크, 컨트롤러, 그리고 캐시)과 네트워크 대역폭의 영향을 받습니다.
I/O 서브 시스템
I/O 서브시스템의 처리 능력은 병렬로 구성된 디스크의 수에 의해 결정됩니다. 최근의 SCSI 나 SAS 디스크는 일반적으로 하나의 디스크에 약 40MB/s의 쓰기 스트리밍을 할 수 있습니다. 스트라이프(striped) 구성일 경우에는 디스크를 분산해서 병렬로 I/O 를 기록하므로 처리 속도도 디스크 개수만큼 배수로 증가할 수 있습니다. 가령, 40MB/s 디스크를 RAID-0 또는 RAID-1+0 구성으로 3개를 사용할 경우는 120MB/s, 5개일 경우에는 200MB/s의 처리 속도를 기대할 수 있습니다.
일반적으로 미러링(RAID-1) 방식은 처리 속도 향상에 거의 영향을 주지 않습니다. RAID-5 방식은 처리 속도를 향상시켜 주지만 스트라이핑에 비해서는 다소 느린 편입니다.
네트워크
네트워크 처리량은 일반적으로 트래픽의 양과 네트워크 인프라(routing/switching) 장비에 의해 결정됩니다. 하지만 일반적으로 bsr을 위한 복제 링크는 전용선을 사용하기 때문에 이런 환경 조건들과는 크게 관련이 없습니다. 따라서 네트워크 처리량은 higher-throughput 전송대역(10 Gigabit Ethernet처럼)으로 전환하거나, 본딩 네트워크 드라이버 같은 복수의 링크를 통해서 향상시킬 수 있습니다.
처리속도 추정
처리 속도를 추정할 때는 다음과 같은 제한사항을 고려해야 합니다.
원시 I/O 서브시스템
네트워크 대역폭
이론적으로는 두 요소의 각각의 최대값 중에서 최소값을 최대 처리 속도로 추정할 수 있으며, 이 값에 오버헤드를 약 3% 정도로 가정해서 속도를 추산합니다.
200MB/s 처리 능력이 있는 I/O 서브시스템에서 기가 비트 이더넷이 연결된 클러스터 노드를 가정해 봅시다. 기가 비트 이더넷의 TCP 연결은 110MB/s 처리 속도를 제공한다고 가정하고, 네트워크의 병목현상을 감안해 3% 정도를 낮춰서 대략 107MB/s의 최대 처리 속도를 기대할 수 있습니다.
또한, I/O 서브시스템에서 100MB/s의 처리 능력이 제공된다고 했을 때 이곳에서의 병목현상까지 감안하여 bsr의 최대 처리 속도는 전체 97MB/s까지 기대할 수 있습니다.
처리량 최적화 튜닝
bsr의 성능에 영향을 줄 수 있는 몇 가지 구성 옵션 중, 이 장에서는 몇 가지 권장할 만한 사항들을 소개합니다. 하지만 성능은 하드웨어에 크게 좌우되기 때문에 여기서 설명한 옵션들을 조정한 효과는 시스템마다 다를 수 있습니다. 따라서 이러한 권장사항들이 모든 병목현상을 해결해주는 절대적인 요소는 아닙니다.
req-buf-size
Primary 노드의 I/O requet 버퍼 큐의 최대 크기를 지정합니다. 이 버퍼는 로컬 디스크로 I/O 가 발생되면 해당 I/O 를 1차적으로 큐잉하기 위한 장소로 송신버퍼로 I/O Request 가 넘겨지기 이전에 1차 버퍼링을 위한 용도로 사용됩니다.
복제가 원할한 보통의 경우에는 req-buf 가 혼잡상황(full)에 놓일 일이 거의 없지만 어떤 요인으로 인해 시스템의 부하가 클 경우 복제 처리가 지연 될 수 있고 req-buf가 full 이 될 가능성이 있습니다.(이 정도의 복제 지연과 부하에 놓인 상태라면 ack 지연으로 인한 복제연결 단절이 발생할 수도 있습니다.) 이러한 상황에 대해 대비하기 위해 req-buf 를 여유있게 설정할 필요가 있습니다. 기본값은 리소스 당 100MB 바이트 입니다.
max-buffers
max-buffers는 타깃의 디스크에 데이터를 쓰기 위해 할당된 peer request 버퍼의 최대 수로 secondary 노드의 쓰기 성능에 영향을 줍니다. 기본값은 16000이고 약 8000 정도면 대부분의 하드웨어 RAID 컨트롤러에서 좋은 성능을 냅니다.
max-buffers 값은 최소한 max-epoch-size 값보다 크거나 같아야 합니다.
resource <resource> {
net {
max-buffers 8000;
max-epoch-size 8000;
...
}
...
}
al-extents
bsr 을 사용하는 응용 프로그램이 쓰기 위주이고 작은 크기의 쓰기를 자주 하는 환경이라면 액티비티 로그 사이즈를 크게 잡는 것이 좋습니다. 그렇지 않으면 메타데이터의 업데이트가 자주 발생하여 쓰기 성능이 저하될 수 있습니다. 기본값은 6001 입니다.
resource <resource> {
disk {
al-extents 6001;
...
}
...
}
지연시간
bsr의 지연(latency) 최적화에 대해 다룹니다. 지연시간을 최소화하기 위해 하드웨어 측면에서 검토하고 몇 가지 설정 옵션을 살펴보겠습니다.
하드웨어
bsr의 수행 시간은 기본 I/O 서브시스템(디스크, 컨트롤러 그리고 캐시)의 수행 시간 및 네트워크의 처리시간에 영향을 받습니다.
I/O 서브 시스템
I/O 서브시스템의 수행 시간은 주로 디스크의 회전속도(RPM)에 의해 정해집니다. 따라서 RPM이 더 빠른 디스크를 사용하는 것이 수행 시간을 개선할 수 있는 올바른 접근 방법입니다.
마찬가지로 배터리 장착 쓰기 캐시(battery-backed write cache-BBWC)를 사용하는 경우도 쓰기시간을 줄일 수 있습니다. 최근 대부분의 스토리지 장비에서는 이런 캐시가 장착되어 있고 읽기 쓰기 캐시 비율을 관리자가 설정할 수 있습니다. 쓰기 I/O의 성능을 높이려면 읽기 캐시를 없애고 쓰기 캐시에 모두 사용할 것을 권장합니다.
네트워크
네트워크 수행 시간은 본질적으로 패킷이 호스트에서 호스트까지 왕복하는 데 걸리는 시간(RTT)을 의미합니다. 여기에 영향을 줄 수 있는 요소들은 몇 가지가 있지만 전용선 환경에서는 이러한 요소에 거의 영향을 받지 않으므로 복제 회선은 직접(back-to-back) 연결된 네트워크를 사용하는 것이 좋습니다. 이처럼 일정한 병목이 유지되는 환경에서 기가비트 이더넷을 사용한다면 지연시간은 일반적으로 100~ 200 microseconds (μs) 패킷 RTT 정도가 될 것입니다.
지연시간 추정
처리량과 연계된 지연시간을 추정할 때, 몇 가지 고려해야 할 중요한 제약 사항이 있습니다.
지연시간은 RAW I/O 서브 시스템 성능과 가용한 네트워크 병목시간의 범주 내에 있습니다.
이 두 시간의 합이 이론상으로는 bsr에 영향을 주는 최소의 지연시간이 됩니다. 그리고 여기에 1% 보다 작은 값을 조금 더 추가시킵니다. 예를 들어 로컬 디스크의 지연시간이 3ms이며 네트워크 지연이 0.2ms인 경우, 예상되는 bsr의 지연시간은 3.2ms입니다. 그냥 로컬 디스크에 쓰는 것보다 지연시간이 약 7% 증가하게 됩니다. 지연시간은 CPU 캐시 미스, 컨텍스트 스위칭(Context Switching)등의 몇 가지 다른 요소들에 의해서도 영향을 받습니다.