소개
이 글은 백업과 복구시에 사용되는 블럭의 최적 사이즈를 지정함으로써 테잎 드라이브의 퍼포먼스를 튜닝할 수 있는 팁과 예제에 대해 설명 합니다. 다음과 같은 주제를 다루게 됩니다:
- 배경지식
- 테스트베드 스펙
- 베이스라인(Baseline) 계산
- 문제의 원인: 기본 블럭킹 요소(Blocking factor)
- 블럭 사이즈 조정하기
- 패턴: 백업보다 복구가 시간이 더 많이 걸림
- 최적의 블럭 사이즈 결정하기
- 첫번째 테스트
- 두번째 테스트
- 결론: 최적의 블럭 사이즈 사용하기
- 저자에 관하여
배경지식
솔라리스를 운용하고 있는 시스템에서 사용되는 테잎 드라이브의 퍼포먼스 튜닝은 자주 간과되곤 합니다. 많은 시스템 관리자들이 최신, 그리고 최고의 테잎 기술을 그들의 백업 환경에 일부로 채택하고 있습니다. 그리고 백업이 "충분히 빨라서" 백업 타임 제약시간 안에만 수행 되기만 하면 그들은 시스템이 전보다 나아졌다고 합니다. 수많은 테잎 드라이브 벤더들이 내놓은 통계 자료를 보면 디바이스는 항상 동일한 스피드로 동작한다고 가정 합니다.
이러한 작업들은 이후에 재앙, 혹은 적어도 가장 어려운 문제가 될 것입니다. 백업 요구사항은 점점 증가(혹 몇몇 경우엔 폭팔적으로) 하여 어느 시점이 지나면 백업이 더 이상 프로덕션 환경에 배정되어 있는 시간 안에 완료 되지 못할 것입니다. 최악의 경우에 여기서에 시간이 재해 복구 연습 시간이 될 수도 있고 혹은 실제로 재해가 발생해서 대용량의 데이타 복구가 필요할 때의 시간이 될 수도 있습니다.
이러한 상황이 되서야 대부분의 시스템 관리자들은 그들의 테잎 드라이브가 발표된 스펙 보다 훨씬 느림을 발견하게 됩니다. 종종 시스템 관리자는 백업은 "충분히 빠르지만" 복구는 복구-시간 목표의 최악의 서비스-수준 협약(service-level agreement) 조차 만족하지 못함을 알게 됩니다. 복구는 벤더가 기술했던 데이타 전송 수준의 최소 수준도 만족시키지 못하기도 합니다.
운나쁘게도 이것은 벤더의 잘못이 아닙니다. 비록 벤더가 공인 벤치마크에서 최고의 숫자를 만들어 낼 수 있도록 데이타, 디스크 서브시스템, 서버들을 튜닝하였더라도 디바이스들 자체는 실제로 발표된 수준, 적어도 백업에서는, 까지 충분히 동작이 가능합니다. 일반적으로 대부분의 네이티브 커맨드들의 기본 설정은 현대 테잎 기술과는 동떨어진 구시대의 것들입니다.
테잎 드라이브가 염려될때에는 약간의 연구와 실험이 큰 차이를 만들어 낼 수 있습니다. 수많은 요소들, 예를 들어 디스크 서브시스템, 물리 메모리의 용량, 공유 메모리 설정 그리고 논리적 볼륨 관리 소프트웨어 조차, 백업과 복구의 퍼포먼스에 영향을 줄 수 있습니다. 그러나 가장 큰 이득을 볼 수 있는 기본적인 튜닝 전략은 쓰기와 읽기시에 사용되는 블럭 요소를 튜닝 하는 것입니다.
엔터프라이즈 백업 제품 사용시에 블럭을 조정하여 실험하는 것은 어려울 수도 있습니다. 각각의 소프트웨어 벤더는 고유의 튜닝 방법을 가지고 있어서 쉽게 조정이 불가능 할 수도 있고 프로덕션 환경에서 실험하기 어려울 수도 있습니다. 좀 더 적절한 방법은 솔라리스의 네이티브 툴을 이용해서 여러분의 환경에 맞는 튜닝 값들을 찾고 그 다음에 여러분의 백업 소프트웨어 벤더의 문서나 서포트 엔지니어를 통해서 여러분이 찾아낸 사항들을 엔터프라이즈 백업 소프트웨어에 적용할 수 있도록 도움을 받는 것입니다.
테스트베드 스펙
이 글의 이후 섹션에서는 실제 테스트-베드 시스템에서 생성된 성능 숫자들에 대해 언급합니다. 인상적인 결과를 위해서 우리는
최신의 테잎 드라이브를 사용했습니다:IBM 3580L33 Ultrium 3 tape drive (LTO-3 로 알려져 있고
여기서 "LTO" 는 "Ninear Tape-Open" 을 의미 함). 이 드라이브는 /dev/rmt/1
로써 상대적으로 빠른 SPARC 서버의 Sun StorEdge PCI Dual Ultra3 SCSI Host Adapter 에
부착 되어졌습니다. (Sun Fire v880 서버 8x900MHz CPU 와 32G 의 물리 메모리에 솔라리스10 08/07
을 운용함.)
테스트 데이타를 위해서 저희는 2G의 정크 파일을 mkfile 을 이용해서 /mnt 밑에 생성하였습니다. 이 데이타가 실제의 데이타를 대표할 필요는 없기 때문에 테잎 드라이브 튜닝에 대한 기본 개념과 의미 있는 퍼포먼스 데이타를 만들어 내는 데에는 아무 무리가 없을 것입니다.
베이스라인(Baseline) 계산
테스트들은 2G 정크 파일을 반복적으로 백업 및 복구하는 기본 솔라리스 커맨드를 반복적으로 사용하여 수행되었습니다. 퍼포먼스 통계를 위해서 우리는 아래와 같이 time 커맨드를 이용하였습니다:
# time tar cvf /dev/rmt/1 /mnt/junk
이 커맨드는 /mnt/junk 파일을 tar 포맷으로 /dev/rmt/1 테잎 드라이브에 저장하고 작업에 걸린 총 시간을 리턴해 줍니다. 또한 User 및 Sys 시간을 리턴해 주는데 이 시간은 각각 입력대기에 걸린 시간과 시스템 작업이 완료 대기 시간을 의미 합니다. 약간 세련되지 않긴 하지만 time 은 적당한 튜닝 값 범위를 결정할 수 있는 의미 있는 퍼포먼스 숫자를 만들어 내는데에 있어서는 충분히 정확합니다.
간단한 계산으로 우리는 커맨드의 "속도" 를 Mbytes/sec 로 알아낼 수 있습니다. 우리가 2G 의 데이타 (2048 Mbytes) 의 데이타를 옮기고 있는 것을 알고 있고 time 커맨드를 통해서 작업이 몇초만에 수행됐는지를 알아낼 수 있습니다. 단순히 2048 을 time 커맨드에서 나온 Real (초단위로 변환됨) 의 출력 결과로 나누면 데이타 전송 속도를 알 수 있습니다.
예를 들어 우리가 time 이 34분, 8초 (2048 초) 걸린 커맨드를 실행했다고 하면 우리는 데이타 전송 속도가 2048 Mbyte / 2048 seconds = 1 Mbyte/sec 임을 알 수 있습니다.
몇가지 기준 숫자를 만들기 위해서 우리는 tar 와 기본 블럭 요소를 이용하여 2-Gbyte /mnt/junk 파일을 백업 및 복구를 다음과 같이 수행 하였습니다.
백업:
# time tar cvf /dev/rmt/1 /mnt/junk
Real: 2:13.7
User: .6
Sys: 10
위 명령은 총 2분 13.7 초의 실행 시간(133.7 초) 걸렸습니다. 이전의 수식을 이용해서, 우리의 기본 tar 백업은 15.32 Mbyte/sec 의 속도로 수행됐습니다. 이것은 알려진 LTO-3 기술의 네이티브 스피드 80Mbyte/sec 훨씬 느린 것입니다.
복구:
# time tar xvf /dev/rmt/1
Real: 2:07.1
User: 11
Sys: 1:02.3
위 명령은 127.1 초의 실행시간이 걸렸고 스피드는 16.11 Mbyte/sec 입니다. 또한번 이것은 LTO-3 기술의 알려진 처리량보다 훨씬 낮은 수준 입니다.
dd 커맨드를 기본 설정으로 수행해서 비교해 보겠습니다:
백업:
# time dd if=/mnt/junk of=/dev/rmt/1
Real: 15:25.0
User: 23.5
Sys: 1:52.0
이번에 백업은 현저하게 느린 15 분 25 초 (925 초) 에 스피드는 2.21 Mbyte/sec 입니다. 이것은 또 하나의 절망적인 발견 입니다.
복구:
# time dd if=/dev/rmt/1 of=/mnt/junk
Real: 17:30.5
User: 32
Sys: 2:59.0
복구는 17 분 30.5 초 (1050.5 초) 에 스피드는 1.95 Mbyte/sec 입니다. 이 시간은 테잎드라이브가 발행한 네이티브 처리량의 1/40 정도의 수준입니다.
문제의 원인: 기본 블럭킹 요소(Blocking factor)
여기서의 트릭은 tar 와 dd
커맨드가 수년 전에 작성되어 졌고 이 당시에는 테잎 드라이브가 지금 처럼 빨리 동적하리라고 생각하지 못했던 시절이였다는
것입니다. 여기서의 키는 사용된 블럭킹 요소 (혹은 블럭 사이즈) 입니다. 이 값은 기본적으로 테잎으로 쓰거나 테잎에서 읽는
대용량의 데이타를 가지고 있는 버퍼와 같은 역활을 합니다.
이 블럭 사이즈를 튜닝하는 것은 테잎 드라이브가
다음의 대용량 데이터를 쓸 준비가 될때 까지 충분한 양의 데이타를 가지고 있도록 함으로써 테잎 드라이브를 계속해서 바쁘게
유지하도록 합니다. 반대로 복구시에는 시스템 디스크를 계속해서 바쁘게 유지할 수 있도록 테잎 드라이브가 이 버퍼를 빠르게 채울
수 있습니다.
tar 커맨드는 1에서 시스템의 가용한 메모리에 의해 정의된 숫자 까지 지정될 수 있는 정수의 블럭킹 요소를 사용 합니다. tar 의 멘페이지에 따르면 각각의 요소는 512 bytes 와 동일합니다. 그리고 만약 어떠한 옵션도 주어지지 않으면 tar 는 기본 블럭킹 요소를 20 (혹은 10240 bytes = 10 Kbytes) 로 가정 합니다. 이 기본 값은 아주 아주 오래전에 구식 1/4 인치 스트리밍 테잎을 가지고 있던 프로그래머에 의해서 선택된 값입니다.
이
기본 값은 그 당시의 대부분의 테잎 기술에 적당하도록 여러번의 시도와 실험에 걸쳐서 선택된 값입니다. 그리고 이 값은 이후로
계속해서 수정되어 왔지만 이러한 수정이 현재의 테잎 기술과 보조를 맞추고 있지는 못합니다. 짧게 말해서 tar 의 기본 블럭킹 요소는 LTO-3 기술 같은 현대의 테잎 기술에서 사용하기엔 너무 낮은 값입니다.
dd 커맨드 또한 예전에 작성되어 졌고 UNIX 에서 가장 오래된 I/O 커맨드 중에 하나 입니다. dd 의 멘페이지에 따르면 dd 는 기본적으로 블럭 사이즈를 512 bytes 로 가정합니다. (tar
보다 20배 더 작은 값임!) 512 bytes 는 그시대에 대부분의 디바이스가 사용하던 네이티브 블럭사이즈였고 특히 1/4
인치 스트리밍 테잎에서 사용 됐었습니다. 다시한번 말해서 우리는 아주 구시대의 기술을 위해 튜닝된 네이티브 커맨드들을 사용하고
있습니다. dd 커맨드는 tar 에 비해 한가지 큰 장점을 가지고 있는데 그것은 블럭 사이즈를 512 bytes 의 배수 가 아닌 임의의 사이즈로 지정할 수 있다는 것입니다.
블럭킹 요소 혹은 블럭 사이즈는 백업 속도 최적화를 위해 조정될 수 있습니다. 그러나 블럭킹 요소의 조정은 복구에 영향을 미칠 수 있습니다.
tar 커맨드는 유용한 기능을 가지고 있습니다. 만약 복구시에 지정된 블럭킹 요소가 테잎을 만들때 사용한 것 보다 더 크다면, tar 는 자동으로 하향된 숫자로 조정해 줍니다. 만약 복구가 백업시에 지정된 블럭킹 요소 보다 더 낮은 숫자를 사용하려 한다면, 그러나, tar 는 읽기 오류로 실패 할 것입니다. 이 동작을 이해 하는 것은 여러분이 테잎을 건내주고 이것이 tar
포맷이라고 얘기해주고 테잎에서 데이타를 끄집어 내야 한다고 얘기하였지만 블럭킹 요소에 대한 어떠한 단서도 주지 않았을 경우,
이러한 상황에서 매우 유용 합니다. 이러한 경우 여러분은 단순히 기본 값이 실패 하였을때 임의로 큰 블럭킹 요소를 사용할 수
있고 복구가 실행될때 까지 지속해서 값을 늘려 주면서 시도해 볼 수 있습니다.
dd 커맨드는 어떠한 편의도 제공하지 않기 때문에 블럭킹 요소에 대해 모른다면 여러분은 사무실에 긴 하루를 보내게 될 것입니다.
블럭 사이즈 조정하기
조정된 블럭 사이즈의 효과를 확인 하기 위해 이전의 기본값 보다 훨씬 큰 256-Kbyte 블럭을 이용해서 백업및 복구를 다시 한번 수행해 봅시다. 얼마나 구식의 값이 사용되었는지를 상기 한다음 다시 한번 숫자를 확인해 봅시다. tar 커맨드를 기억해보면 우리는 256 Kbytes 를 512 bytes 로 나눈 값을 사용할 것입니다 (이 숫자는 512 입니다, 512 * 512 = 256 Kbytes), 그리고 dd 커맨드는 실제 킬로바이트로 표현된 숫자를 사용할 것입니다 (256k).
tar 를 이용한 백업:
# time tar cvfb /dev/rmt/1 512 /mnt/junk
Real: 28.1
User; 0.0
Sys: 3.5
위의 결과는 2048 Mbyte / 28.1 초 = 72.88 Mbyte/sec 의 속도를 보여줬고 이것은 LTO-3 테잎의 발행된 통계와 거의 근접한 숫자 입니다.
tar 를 이용한 복구:
# time tar xvfb /dev/rmt/1 512
Real: 1:23.2
User: 10.5
Sys: 56.2
실행결과 2048 Mbyte / 83.2 초 = 24.62 Mbyte/sec 의 속도를 보여줬고 이것은 아직 우리가 기대했던 만큼의 숫자는 아니지만 이전 보다는 훨씬 좋아 졌습니다.
dd 를 이용해서 블럭 사이즈 (bs) 를 256k 로 지정하고 백업해 봅시다:
# time dd if=/mnt/junk of=/dev/rmt/1 bs=256k
Real: 28.0
User: 0.0
Sys: 3.5
실행결과 2048 Mbyte / 28 초 = 73.14 Mbyte/sec 의 속도를 보여주었습니다.
dd 를 이용해서 블럭 사이즈 (bs) 를 256k 로 지정하고 복구해 봅시다:
# time dd if=/dev/rmt/1 of=/mnt/junk bs=256k
Real: 36.5
User: 0.0
Sys: 7.5
실행결과2048 Mbyte / 36.5 초 = 56.11 Mbyte/sec 의 속도로 지금까지 복구 속도중에 제일 빨랐습니다.
패턴: 백업보다 복구가 시간이 더 많이 걸림
각각의 경우에서 time 에 의해 보고된 시간을 쪼개서 비교해 보면 추가적인 패턴을 발견하게 됩니다. 명확하게 대부분의 경우에서 복구가 백업보다 시간이 더 많이 걸립니다. tar 를 이용한 복구는 User 와 Sys 값이 꽤 높게 나타났고 이것은 작업에 더 큰 프로세싱 오버헤드가 걸림을 나타 냅니다. 우리가 얻은 최상의 경우에서 복구는 백업에 약 70% 정도의 속도로 수행(dd 를 블럭 사이즈 256K 를 지정해서 실행했을 때) 되었습니다. 이것은 즉 튜닝이 수행되면 일반적으로 백업 속도는 증가 하지만 여전히 복구는 백업 보다 느리다는 것을 보여 줍니다.
많은 시스템 관리자들이 복구 속도가 백업속도와 비슷할 수 있을 것이라는 함정에 빠지지만 결국엔 대용량의 데이타 셋을 복구 할 때 왜 시간이 오래 걸리는지, 혹은 그들이 약속한 시스템 복구 시간을 만족시키지 못함을 갑자기 알게 되고 백업 및 복구 전략을 재 검토하는데에 엄청난 시간을 소비하게 됩니다. 완벽한 테스트의 선행 없이는 절대로 복구 속도가 백업 속도와 근접할 것이라고 가정하지 마시기 바랍니다!
최적의 블럭 사이즈 결정하기
이제 우리는 신형 혹은 빠른 테잎 드라이브는 우리가 블럭 사이즈를 적절하게 지정해 줬을때에만 실제 잠재력을 발휘할 수 있음을 알게 되었습니다; 러면 우리는 어떻게 실제 최적의 값을 결정 할 수 있을까요? 퍼포먼스에 영향을 줄 수 있는 수 많은 요소들을 고려해 보면 이 질문은 쉽게 대답하기 힘듭니다.
한가지 취할수 있는 방법은 서버의 데이타의 양(CPU 의 갯수, CPU 속도, 스왑, 공유 메모리 설정, 디스크 타입, RAID 레벨 등등)을 최대한 프로덕션 환경으로 부터 복제하는 것입니다. 그 다음에 각각 다른 블럭 사이즈로 테스트 케이스를 수행한 다음에 최적에 값을 찾아 내는 것입니다. 대부분의 요즘 테잎 드라이브들은 실제로 단일 디스크의 속도 보다 훨씬 빠르므로 RAID 를 이용해서 복수개의 데이타를 복수개의 디스크에서 가져오는 설정을 이용하지 않으면 백업 스피드가 현저히 떨어짐을 발견하게 될 것입니다.
어떠한 값을 가지고 작업을 할것인지는 또한 여러분의 프로덕션 환경 우선순위에 따라 결정 되어야 합니다. 저녁 시간대의 짧은 백업에 맞추고자 한다면 백업 속도를 우선으로 하고 복구의 속도를 희생시킬 것입니다. 대용량 데이타셋 복구의 시간을 줄여서 복구 시간을 최소화 하고 백업 시간이 더 오래 걸리는 것을 원할 수도 있습니다. 대부분의 경우 여러분은 두가지 사이의 밸런스를 깨야 되고 이것은 여러분의 환경의 필요에 따라 결정되어야 합니다.
첫번째 테스트
다음의 예제에서 우리가 다룰 테스트 데이타는 여러분의 프로덕션 환경에서 보게될 것과 는 매우 다른 패턴들을 따름을 알게 될
것입니다. 여러분들은 더 빠른 혹은 더 느린 디스크, 다른 서버들간의 다른 커널 튜닝 파라미터, 다른 SCSI 어답터, 그리고
다른 퍼포먼스 프로파일을 생성할 수도 있는 기타 사소한 차이점들이 있을 수 있습니다. 여기에서의 예제는 오직 데모의 목적입니다.
우리는 dd 를 서로 다른 블럭 사이즈를 이용해서 백업과 복구를
추적해 보고 값을 조금씩 증가시켜서 일반적인 패턴을 얻어 낼 것입니다. 블럭 사이즈가 증가함에 따라 퍼포먼스가 증가할 것이지만
점차적으로 작은 양이 증가할 것입니다. 혹은 블럭 사이즈의 증가가 특정 시점 까지는 퍼포먼스의 증가를 이끌다가 점점 효과가
없어질 수도 있습니다. 또한 최대(peak) 퍼포먼스 숫자가 하나 이상임을 발견할 수도 있을 것이고 백업과 복구의 서로 다른
패턴을 볼 수도 있을 것입니다.
이러한 패턴들은 각각의 시스템에 특성에 따라 달라질 것입니다, 그러므로 여러분이
퍼포먼스 최적화를 하고자 하는 환경과 최대한 비슷하게 복제를 하는 것이 중요 합니다. 또한 한 서버에서의 최적의 값이, 혹은
백업 복구의 하나의 셋이 반드시 다른 환경에서 최적이지 않을 수도 있습니다.
백업은 아래와 같은 커맨드를 이용해서 테스트 할 것이고 여기서 <X> 는 블럭 사이즈 입니다:
# time dd if=/mnt/junk of=/dev/rmt/1 bs=<X>
그리고 아래의 커맨드를 이용해서 복구를 테스트 할 것입니다:
# time dd if=/dev/rmt/1 of=/mnt/junk bs=<X>
여기서 알아둘 점은 복구를 수행하기 전에 각각의 백업 이후 "정크" 파일들을 반드시 지우고 난 후에 각각의 복구가 끝난 후 mkfile 을 이용해서 다시 생성해 주어야 합니다. 이렇게 함으로써 dd
의 경향과 부주의로 인한 파일 사이즈의 변경을 보정할 수 있습니다. 이 파일은 기본적으로 스왑 파일을 생성하기 위한 고정된 비트
패턴이기 때문에, 블럭 사이즈 변경 및 일반적인 프로덕션 환경에서 쉽게 볼 수 없는 압축 알고리즘에 의한 이상한 부작용들이
축적되기 쉽습니다.
우리는 매우 다양한 범위의 값을 사용하므로써 데이타의 패턴이 존재 하는지, 그리고 어떠한 블럭 사이즈를 좀 더 연구해볼 필요가 있는지를 살펴 볼 것입니다. 우리는 각 블럭 사이즈 마다 오직 단 한번의 백업 및 복구를 수행함을 기억하시기 바랍니다. 그러므로 이번 실행에서는 통계적은 오류가 발생할 수도 있습니다. 일단 기본 베이스라인을 얻은 다음에는 집중할 몇가지 값들을 선택하고 좀더 통계적으로 의미 있는 데이타를 얻어낼 것입니다.
bs 를 16k, 32k, 64k, 128k, 256k, 512k, 1024k, 2048k, 4096k, 그리고 8192k 로 각각 조정해서 테스트 해보면 (기본적으로 2의 배수로 증가) 다음과 같은 데이타를 얻게 됩니다.
|
표 1: 백업 및 복구의 테스트 결과
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||
백업의 최대(peak) 퍼포먼스는 블럭 사이즈가 2048k 로 지정됐을때 나타나고 복구의 최대(peak) 퍼포먼스는
512k 일때 나타 납니다. 우리의 데이타에서는 백업 및 복구 쪽에서 블럭 사이즈를 증가시킬때 마다 대략적으로 bell 커브
형태를 나타 냅니다; 그러나 각각은 서로 다른 지점에서 정점(peak)을 보입니다.
다시한번 말하자면 우리는
각각의 데이타 포인트 마다 단 한번만 수행을 했기 때문에 전체적으로 안정적인 정보를 가지고 있다고 볼 수 는 없습니다. 64k
에서의 매우 빠른 복구 속도를 참고하시기 바랍니다. 이 결과가 이 블럭 사이즈에서의 평균 속도를 나타낸다고 보긴 어렵습니다.
왜냐하면 다른 데이타들과의 일관성이 없기 때문입니다.
좀 더 파고 들기 위해 우리가 관찰한 최대(peak) 숫자들 사이의 값을 자세히 살펴 볼 것입니다. 각각의 블럭 사이즈 레벨 마다 몇차례 테스트를 수행하고 평균을 낸 다음 이 평균을 가지고 우리의 결정의 기반으로 삼을 것입니다. 우리의 예에서는 각각의 블럭마다 5번이ㅡ 테스트를 수행했고 좀 더 많은 테스트를 수행할 수 록 좀 더 정확한 최종 결과를 얻을 수 있을 것입니다. 각각의 데이타 포인트 마다 적어도 10번 이상씩은 하는 것이 좋을 것입니다.
우리는 좀 더 자세한 테스트를 위해서 블럭 사이즈 값으로 256k, 512k, 1024k, 그리고 2048k 을 이용할 것입니다.
|
표 1: 백업 및 복구의 테스트 결과
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
테스트 결과에서 얻어진 데이타를 통해서 우리는 5개 테스트의 결과 평균이 매우 비슷함을 알 수 있습니다. 백업은
2048k 사이즈에서 매우 작은 차이로 최고의 속도를 보였고 복구는 .5 Mbyte/sec 차이 밖에 나지 않았습니다.
데이타는 최적 값이 위의 숫자들 사이에 있음을 가르키고 있습니다. 만약 백업을 최적화 하고자 했다면 아마 2048k 럭 사이즈를 선호할 것입니다. 그리고 비록 여러분이 모든 테스트 결과 시간 동안에 가장 안정적인 복구 시간을 보인 블럭 사이즈를 선호 한다고 하더라도 대부분의 블럭 사이즈들은 기본적으로 모두 괜찮습니다.
복구 시간을 좀 더 자세히 살펴 보면 복구는 512k 블럭 사이즈에서 가장 안정적인 결과를 나타 냈습니다.
우리의 데이타가 우리를 옳은 길로 인도하고 있다고 하더라도 이것은 소모적인 테스트로 간주되어서는 안됩니다. 실제 상황에서 우리는 아마도 동일한 숫자 범위 안에서 수행된 결과를 자세히 관찰하길 원했을 것이고 적합한 수준에 다달았다고 할때 까지 블럭 사이즈를 늘려갈 것입니다. 좋은 프랙티스로는 우리가 이전에 했던 것처럼 광범위한 숫자들을 이용하고 그 다음 각각의 숫자들 사이의 모든 가능성들에 대해 다시 한번 테스트 해 볼 것입니다.
만약 좀 더 자세히 알아보고자 했었다면 256k 부터 시작해서 1024k 에 닿을때 까지 64k 씩 증가시키면서 평균 10번 정도의 테스트를 수행 했을 것입니다.
물론 이러한 숫자들이 모든것을 말해 주지는 않습니다. 우리의 데이타 전송율을 인공적으로 제한 하는 병목점이 존재할 수도
있습니다. 하드 디스크 자체도 병목점이 될 수 있고 테잎드라이브가 데이타를 가져가는 것 만큼 빠르게 데이타를 생산해 내지 못할
수도 있습니다. (그리고 반대로 하드 드라이브가 복구시에 테잎 드라이브가 전송하는 데이타를 처리할 만큼 빠르지 않을 수도
있습니다). 이전에 결정한 최적이ㅡ 블럭 사이즈를 확인하기 위한 유용한 테스트는 디스크 서브 시스템을 그림에서 제거하는
것입니다. 우리는 디스크-기반의 테스트 파일 대신에 레지스터로써 지속적으로 8개의 0으로 만들어진 bytes 를 내뱉어 주는 /dev/zero 시스템 디바이스를 사용할 수 있습니다.
/dev/zero 를 사용하는 것은 또다른 장점이 있습니다: 일관적인
간단한 비트 패턴의 스트림은 테잎 드라이브의 하드웨어 기반 압축이 처리하는데에 있어서 가장 간단한 데이타 셋 입니다. 0 으로만
이루어진 문자열은 세계에서 가장 간단한 패턴이고 또한 가장 원시적인 압축 루틴도 이것을 최고의 효율성으로 다룰 수 있습니다.
두번째 테스트
두번째 테스트를 위해 우리는 처리량을 결정하는 다른 방법을 사용해야 합니다. /dev/zero 은 끈임없이 계속되는 스트림이기 때문에 어떠한 백업도 중간에 프로세스를 방해하지 않는 이상 테잎이 다 소모될때 까지 끝나지 않을 것입니다. 그러므로 time 커맨드는 불가능 합니다. 또한 /dev/zero 는 사실상 사이즈가 무한하기 때문에 time 을 이용해서 실행시간을 알아낼 방법이 없습니다.
또한 베이스라인으로 사용할 수 있는 고정된 데이타의 사이즈가 존재하지 않습니다. 대신에 우리는 iostat 커맨드를 다른 윈도우 창에서 띄워서 dd 커맨드를 이용하는 동안 실제 처리량을 볼 수 있습니다. 가독성을 위해서 우리는 -Mnx 옵션을 1 간격으로 이용해서 I/O 활동의 스냅샷을 매 1초마다 확인 하고, 처리량을 Mbyte/sec 단위로 출력하고 아래와 같이 인스턴스 번호 대신에 각각의 디바이스의 논리적 이름을 출력 합니다:
# iostat -Mnx 1
백업을 위해서는 아래의 커맨드를 이용합니다. <X> 는 블럭 사이즈 입니다:
# dd if=/dev/zero of=/dev/rmt/1 bs=<X>
이 명령은 /dev/zero 를 우리가 선택한 블럭 사이즈로 테잎 드라이브에 스트리밍 합니다. 이것은 끝없이 실행되므로 우리는 iostat 출력을 테잎 브라이브가 풀 스피드로 돌아갈때 까지 지켜볼 필요가 있습니다. 그리고 Mw/sec (Mbytes written per second) 필드와 %b (percentage busy) 필드를 읽을 필요가 있습니다. 10 초에서 20초 정도면 충분하고 그다음에 Ctrl-C 를 눌러서 커맨드를 중지 시킵니다.
우리는 테잎을 되감은 다음 테잎의 /dev/zero 바이트 스트림을 /dev/null (기본적으로 데이타를 여기로 복구 시킴) 로 덤핑하는 방법을 통해 "시뮬레이션" 복구를 실행합니다. 아래의 커맨드를 이용하고 여기서 <X> 는 블럭 사이즈 입니다:
# dd if=/dev/rmt/1 of=/dev/null bs=<X>
다시한번 말해서 우리는 iostat 출력을 지켜볼 필요가 있고 Mr/sec field (Mbytes read per second) 와 %b (percent busy) 필드를 관찰할 필요가 있습니다. 이전에 했던것과 마찬가지로 블럭 사이즈의 범위에서 이 테스트를 실행할 것입니다: 16k, 32k, 64k, 128k, 그리고8192k 까지. 그 다음 결과를 살펴 봅니다.
|
표 3: 디스크 독립적인 읽기와 쓰기 테스트 결과
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
엄청나꼐 빠른 복구 처리량을 보여준 숫자는 실질적으로 백업 처리량을 능가 함을 볼 수 있습니다. 이것은 부분적으로 우리가 사용한 데이타 셋의 단숨함과 드라이브의 하드웨어 압축 알고리즘이 작업을 최적의 방법으로 처리할 수 있기 때문입니다. 아마도 실제 백업 혹은 복구 (복수개의 백업을 복수개의 디스크에서 동일한 테잎 드라이브로 하지 않는 이상) 에서는 이러한 처리량을 볼 수 없을 것입니다.
이러한 숫자들을 볼때 우리는 제조자들의 그들이 사용하는 raw 데이타가 최고의 효율성으로 압축될 수 있고 테잎 드라이브와 거의 동일한 속도 (혹은 더 빠르게)로 스트림이 들어오고 나갈 수 있음을 이용하여 어떻게 벤치마크를 수행 하는지에 대한 느낌을 얻을 수 있을 것입니다.
이번 테스트에서 우리는 백업과 복구에서 최적의 결과를 내는 블럭사이즈에 좀 더 집중했습니다. 이전과 마찬가지로 우리는 데이타가 대략 bell 커브 형태를 나타냄을 알 수 있습니다: 정점(peak)까지는 천천히 증가하다가 정점 이후에는 서서히 감소함.
커브의 정점은 백업과 복구 모두 2048k 블럭 사이즈에서 나타 났고 이것은 이전의 결과와도 부합 됩니다. 여기서 나온 전송률은 디스크에서 읽기 쓰기를 했던 것보다 훨씬 빠른 것으로 디스크 서브시스템이 명백하게 제한 요소 임을 나타 냅니다.
결론: 최적의 블럭 사이즈 사용하기
그러므로 이제 우리는 최적의 블럭 사이즈를 알아 냈습니다. 이제 이 정보로 무엇을 할 수 있을까요? 답은 여러분이 사용하는 백업 솔루션에 전적으로 달려 있습니다. 만약 tar, dd, ufsdump 같은 네이티브 커맨드를 사용한다면 이것은 여러분의 백업및 복구에 사용하고 있는 커맨드셋에 맞게 블럭킹 요소를 변환함으로써 최적화가 가능합니다.
만약 Symantec Veritas NetBackup, IBM Tivoli Storage Manager, 혹은 EMC Legato Networker 같은 엔터프라이즈 백업 솔루션을 사용하고 있다면 여러분은 여기서 얻은 정보를 백업 및 복구 소프트웨어에 적용할 수 있도록 좀 더 연구해 봐야 할 것입니다. 대부분의 벤더들은 버퍼 사이즈와 블럭킹 요소를 튜닝할 수 있는 방법을 제공하지만 이것은 공식 문서에서도 아주 찾기 어려운 것에 숨겨져 있을 수 있습니다.
각각의 소프트웨어 패키지는 얼마나 여러분이 버퍼 혹은 블럭 사이즈를 튜닝 할 수 있는지에 대한 제약사항이 존재 할 것이고 이러한 경우에는 여러분의 테스트에서 얻은 값과 최대한 가깝게 설정해야 할 것입니다.
추가적으로 버퍼 혹은 블럭킹 값은 추가적으로 관계된 값들의 조정이 필요할 것이고 또한 충분한 공유 메모리가 할당되도록 커널의 파라미터를 조정해야할 필요도 있을 것입니다. 여러분이 앞으로 해야알 작업은 벤더에 따라 다를 것이고 다양한 환경에 따라서도 다를 것입니다. 다음 단계로 진행하기 전에 여러분의 엔터프라이즈 백업 소프트웨어를 튜닝하는 방법에 대해 좀 더 자세히 알아보고 변경할때 마다 결과를 테스트 해 볼 것을 강력히 권장합니다.
벤더의 공식 문서와 덧붙여서 여러분은 인터넷에서 어떻가 다른 사람들이 시스템을 튜닝 할 수 있는지를 찾아 보실 수도 있을 것입니다. 이러한 자료들은 매우 귀중합니다 왜냐하면 여러분의 실수 대신 다른 사람의 실수를 통해서 배울 수 있도록 허락하기 때문 입니다. 만약 여러분이 이러한 절차들을 수행 하던 중에 너무 어렵다고 느끼거나 힘들다면 소프트웨어 벤더에게 서비스 요청을 하는 것이 가장 좋은 선택일 것입니다.
튜닝은 전혀 쉽지 않은 작업이고 우리는 오직 아주 작은 부분만 여기서 다루었습니다. 필자는 여러분이 좀더 훌륭한 처리량을 얻기 위한 시작 과정으로써 귀중한 정보와 안목을 배웠기를 희망합니다.
저자에 관하여
Vincent 는 1994년 부터 솔라리스의 다양한 기능을 다루어 왔습니다. 그는 테이블 오퍼레이터, 헬프 데스크, 백업
관리자, 하드웨어 전문가, 시스템 관리자, 재해 복구 전문가등의 다양한 경험들을 쌓아 왔습니다. 최근에 그는 재해 복구를 위한
인프라스트럭쳐 개발및 지원을 담당하고 있고 또한 문서 작성과 스크립트 프로젝트 그리고 소규모의 연구 프로젝트 같은 부분에 많은
시간을 할애 하고 있습니다. 전문 분야는 JumpStart, 백업 및 복구, 엔터프라이즈 레벨 백업 솔루션, 서버 배치이고 그의
왼쪽 서랍에 응급 상황을 대비해서 예비 부품을 쌓는 작업을 하고 있습니다.
이 글의 영문 원본은
Beginner's Guide to Tape Drive Performance Tuning on Solaris 10 Systems
에서 보실 수 있습니다.
"관리자코너" 카테고리의 다른 글
- 내장 비트맵 폰트를 활성화 시키는 방법 (댓글 0개 / 트랙백 0개) 2008/08/14
- 솔라리스 볼륨 메니저를 이용하여 솔라리스9, 10 에서 루트를 미러링 하는 방법 (댓글 1개 / 트랙백 0개) 2008/09/20
- x86 과 SPARC플랫폼에서 동일한 하드디스크에 여러개의 솔라리스 설치하기 (댓글 0개 / 트랙백 0개) 2008/02/18
- 썬 파이어 T2000 서버에 솔라리스10 에서 IBM DB2 최적화하기 (댓글 4개 / 트랙백 0개) 2006/11/23
- rsync 와 sudo 를 이용한 원격 업데이트 (댓글 0개 / 트랙백 0개) 2008/03/11
- 솔라리스 10 OS 또는 마이크로소프트 윈도우즈용 DHCP 클라이언트 설정 (댓글 0개 / 트랙백 0개) 2008/07/16
- SSH 로그인 세션 자동화 (댓글 1개 / 트랙백 2개) 2006/07/23
- 솔라리스 레디 애플리케이션 및 솔루션 (댓글 0개 / 트랙백 0개) 2008/03/13
- 디렉토리상의 큰 파일들을 검사하는 스크립트 (댓글 2개 / 트랙백 0개) 2005/09/23
- 꼭 써봐야 할 솔라리스 10의 보안 기능 Top 5 (댓글 0개 / 트랙백 0개) 2008/02/13
TRACKBACK :: http://blog.sdnkorea.com/blog/trackback/629
댓글을 달아 주세요
최석호 수정/삭제 댓글쓰기
일반적으로 OS 제공되는 명령어를 사용 하여 Tape 이나 Disk에 Backup 할 경우
어떤 사람들은 tar 명령어를 사용하는데, tar 를 사용하지 마시고 ufsdump 명령어를 사용 하세요.
속도 면에서 훨 빠릅니다. tar 는 1개의 port 로 작업하지만 ufsdump 는 5개의 port 를 열어 진행하기 때문에
속도에서 훨 빠릅니다.
다음은 tar 와 ufsdump 장단점을 개인적으로 올려 봅니다.
=========================================================================
명령어 || 장점 || 단점
=========================================================================
tar = 원하는 파일 디렉토리 가능 =속도가 늦고,레벨을 지정할 수 없음.
-------------------------------------------------------------------------
ufsdump =빠른 성능, 레벨기준 backup 가능 = Filesystem 단위로 해야하기 때문에 규모가 커짐
--------------------------------------------------------------------------
'9. 도서관 > __사. Network' 카테고리의 다른 글
| 솔라리스 ufsdump (0) | 2008.12.26 |
|---|---|
| 우분투 ftp (0) | 2008.12.26 |
| dd 명령을 이용한 디스크 복제 (0) | 2008.12.23 |
| Ubuntu, 부트 시간을 그래프로~ bootchart... 나만 모른겨? (0) | 2008.12.22 |
| minicom (0) | 2008.12.16 |
댓글