소개

IBM Tivoli® Storage Manager는 관리하기에 간편한 수많은 기능을 통해 스토리지 관리 필요성을 해결한다. 이러한 고급 기능은 지능형 백업과 복원, 계층 구조 스토리지 관리, 관리형 아카이브 및 데이터 중복 제거 등을 포함한다. 데이터와 메타데이터 둘 다에 대한 스토리지 요구사항은 어마어마할 수 있다. 메타데이터 스토리지의 IO 병목현상을 제거하기 위해 SSD(Solid-State Drive)를 사용하면, 성능 개선(일부 경우에 최대 229퍼센트)이 많은 Tivoli Storage Manager 기능에 실현될 수 있다. 이 문서는 다른 사람들이 증가를 경험하도록 구성과 튜닝을 제공한다.

위로

혁신(disruptive) 기술

SSD(Solid-State Drive)(또는 고체 상태 디스크라고도 함)는 기존의 돌아가는 디스크(하드 디스크 드라이브, HDD) 등의 움직이는 부분이 없는 지속적 블록 스토리지 디바이스이다. 그 대신에 비휘발성 SSD는 Flash 기반 DRAM 메모리를 사용하여 데이터를 지속한다. 그로 인해 움직이는 부분이 없으며, 이는 지연을 찾는 것을 방지하여 훨씬 더 신속한 액세스 시간을 허용한다. HDD와 동일한 인터페이스는 기존 소프트웨어로 원활한 사용을 허용하는 SSD에 사용된다. SSD는 HDD형 폼 팩터 뿐만 아니라 PCle 어댑터가 제공된다.

위로

IBM Tivoli Storage Manager

IBM Tivoli Storage Manager는 전사적 스토리지 관리 애플리케이션이다. 이는 다양한 운영 체제를 갖춘 파일 서버, 데이터베이스 서버, 워크스테이션, 개인용 컴퓨터의 백업, 복원, 아카이브 및 검색을 비롯한 자동화된 스토리지 관리 서비스를 제공한다.

서버 프로그램

서버 프로그램은 클라이언트에 백업, 아카이브 및 공간 관리 서비스를 제공한다. 누구나 스토리지, 프로세서 및 네트워크 자원의 균형을 맞추기 위해 엔터프라이즈 네트워크에서 여러 서버를 설정할 수 있다.

서버 데이터베이스

Tivoli Storage Manager 서버는 데이터베이스를 사용하여 서버 스토리지, 클라이언트, 클라이언트 데이터 및 스케줄에 대한 정보(예: 메타데이터)를 추적한다. 여기에서 SSD 실험에서는 서버 데이터베이스가 SSD에 상주한다.

서버 스토리지

서버는 디스크와 테이프 스토리지 디바이스 및 광범위한 공급업체 목록에서 나온 서브시스템을 사용하여 데이터를 저장하고 검색할 수 있다. 서버 스토리지 매체는 스토리지 풀로 그룹화된다. 스토리지 디바이스는 서버로 직접 연결되거나 로컬 영역 네트워크(LAN) 또는 스토리지 영역 네트워크(SAN)를 통해 연결될 수 있다.

서버 관리 인터페이스

관리 인터페이스를 통해 관리자는 서버 활동을 제어 및 모니터하고, 클라이언트를 위한 관리 정책을 정의하며 스케줄을 설정하여 정기적으로 클라이언트에 서비스를 제공할 수 있다. 사용 가능한 관리 인터페이스는 명령행 관리 클라이언트 및 웹 브라우저 인터페이스(Administration Center라고도 함)를 포함한다. Tivoli Storage Manager를 사용하면 웹 브라우저를 통해 액세스 가능한 하나의 인터페이스로부터 여러 서버를 관리 및 제어할 수 있다.

백업 아카이브 클라이언트 노드

백업 아카이브 클라이언트를 통해 사용자는 파일의 백업 버전을 유지보수할 수 있으며, 이는 원본 파일이 손실되거나 손상되는 경우에 복원될 수 있다. 사용자들은 장기간 스토리지를 위해 파일을 아카이브하고 필요할 때 아카이브된 파일을 검색할 수도 있다. 백업/아카이브 클라이언트 프로그램은 파일 서버, 데이터베이스 서버, 워크스테이션 및 개인용 컴퓨터에 설치되고 서버로 등록된다.

애플리케이션 클라이언트 노드

애플리케이션 클라이언트를 통해 사용자들은 데이터베이스 프로그램 등의 애플리케이션용 데이터의 온라인 백업을 수행할 수 있다. 다음 제품은 Tivoli Storage Manager 서버와 사용하도록 클라이언트에 애플리케이션을 제공한다. 즉, 이는 Tivoli Storage Manager for Databases, Tivoli Storage Manager for Enterprise Resource Planning 및 Tivoli Storage Manager for Mail이다.

위로

하드웨어 및 소프트웨어 세부사항

다음은 테스트 하의 시스템(SUT) 및 테스트 드라이버의 세부사항이다.

Tivoli Storage Manager 서버, 버전 6, 릴리스 2, 레벨 1

• 2.4GHz의 Intel® Xeon™ E7450(6코어) 프로세서 패키지 4개(총 24 코어)
• 32GB 실제 메모리
• Intel(R) 82575EB Gigabit Network 포트 2개
• I/O Acceleration을 갖춘 Intel(R) PRO/1000 EB Network 포트 2개
• IBM 320GB High IOPS SD Class SSD PCIe Adapter 2개
• Qlogic QLE2460 싱글 포트 4Gbps 파이버 HBA 2개
• Qlogic QLE2560 싱글 포트 8Gbps 파이버 HBA 1개(테이프에 사용됨)
• Microsoft® Windows Server 2008 R2 Enterprise x64 Edition
• Multipath I/O 기능 설치
• IBM Subsystem Device Driver DSM, 버전 2.4.2.1-2
• 8개 랭크 사용하여 DS8100 모델 921에서 256GB 디스크 LUN 8개
• 8개 랭크 사용하여 DS8100 모델 921에서 64GB 디스크 LUN 8개(위와 동일한 랭크)
• 4개의 IBM LTO™ Ultrium® 5개 테이프 드라이브(공유)를 갖춘 IBM TS3500 테이프 라이브러리 1개

Tivoli Storage Manager 클라이언트(32x), 버전 6, 릴리스 2, 레벨 1

• Lenovo ThinkCentre M55 8810-BE2
• 2.66GHz의 Intel Core2 Duo 1개
• 2GB 실제 메모리
• Broadcom NetXtreme Gigabit Network 카드 1개
• 150GB IDE 디스크
• Microsoft Windows XP Professional, SP3

네트워크

• Netgear® GSM7352S 10Gbps/1Gbps 48포트 LAN 스위치
• IBM 2005B32 32포트 4Gbps 파이버 스위치

SSD(Solid-State Drive)

두 개의 IBM 320GB High IOPS SD Class SSD PCIe 어댑터는 Fusion-IO Windows 소프트웨어 버전 2.1.0이 필요했다. SSD 어댑터 펌웨어는 43247 레벨로 모든 어댑터에 업데이트되었다. 해당 디바이스는 기본 광고된 용량으로 낮은 레벨로 형식화되었으며, 이는 각 어댑터에 두 개의 160GB 디바이스를 제공한다. 마지막으로, NTFS 볼륨은 기본 할당 유닛 크기를 사용하여 작성되었다. 하나의 측정치 세트에서 단일 NTFS 볼륨은 하나의 SSD 어댑터 디바이스에 사용되었다. 또 다른 측정치 세트에서 RAID5 볼륨은 네 개의 모든 SSD 어댑터 디바이스를 사용하여 작성되었다.

워크로드 설명

표준 파일 시스템 워크로드 세트는 백업-아카이브 클라이언트 기능 성능 테스트 및 서버 기능 성능 테스트에 사용된다. 표준 파일 시스템 워크로드는 다음 속성이 있다.

• 변수 길이 이름을 사용하여 무작위로 지정된 파일 이름과 디렉토리 이름.
• 10개 레벨의 최대 디렉토리 깊이.
• 디렉토리당 최대 32개 파일.
• 파일은 Tivoli Storage Manager 클라이언트 압축을 사용할 때 3대1의 일반적인 압축 비율이 있는 소스 데이터로부터 작성된다.
• 파일은 각 워크로드 볼륨 내 그리고 모든 클라이언트에서 모든 볼륨들 사이에 효율적으로 중복 데이터가 전혀 없다.
• 총 워크로드 크기는 측정된 기능의 경과 시간, 여러 스레드를 시작하기 위한 요구사항, 필수 측정치 반복 가능성 또는 사용 가능한 디스크 공간 양에 따라 크기 조정된다.
• 워크로드는 새롭게 정의된 파일 시스템이나 새롭게 형식화된 파티션에 작성된다.

개별 워크로드는 평균 파일 크기인 10KB에 따라 작성된다.

이 보고서의 모든 성능 측정치는 그림 1과 같이 격리된 환경에서 나왔으므로, 측정되는 제품을 제외하고 소스로부터 자원 충돌은 없었다. Tivoli Storage Manager 서버는 6+P 또는 7+P RAID 5 어레이를 사용하는 146GB 10K RPM 파이버 채널 디스크 드라이브의 8개의 랭크를 사용하여 DS8100 모델 921에서 8개의 256GB 논리 장치 수(LUN) 및 8개의 64GB LUN이 들어있는 디스크 스토리지로 구성되었다. 각 LUN은 4KB 할당 유닛 크기로 NTFS 파일 시스템을 사용하여 형식화되었다. Tivoli Storage Manager 서버 데이터베이스는 하나의 DS8100 64GB 볼륨, SSD RAID 5 볼륨 또는 SSD JBOD 볼륨에서 하나의 디렉토리에 있다. Tivoli Storage Manager 서버 활성 로그 및 아카이브 로그 파일은 개별 DS8100 64GB LUN에 있다.

Tivoli Storage Manager 서버 데이터베이스는 충분한 오브젝트로 입력되었고 DB2 runstats가 성능 측정을 실행하기 전에 실행되었으므로 데이터베이스 색인의 최적 사용이 달성되었다. 데이터베이스 자동 재구성 기능은 이러한 테스트 도중에 사용되지 않았다.

테이프 디바이스, 마운트 시간 및 볼륨 열기 시간을 사용하는 데이터베이스 백업 측정의 경우 측정치에 포함된다. IBM LTO™ Ultrium® 5 카트리지 테이프 매체 및 테이프 하드웨어 압축(compaction)이 이러한 측정치에 사용되었다. 테이프 형식에 대한 특정 측정치 테이블을 참조한다. 테이프 하드웨어 압축은 이 보고서에서 모든 테이프 측정치에 사용되었다.

이러한 측정의 의도는 DS8100 볼륨, JBOD SSD 볼륨 및 RAID 5 SSD 볼륨에서 하나의 데이터베이스 디렉토리를 사용하는 Tivoli Storage Manager 서버 데이터베이스 사이에 성능을 비교하는 것이다. 이 모든 테스트에서 Tivoli Storage Manager 서버 활성 로그 및 아카이브 로그 디렉토리는 개별 DS8100 어레이에 있고 어느 테스트에서나 병목현상은 없었다.

수많은 변수와 환경적 조건이 성능에 영향을 줄 수 있다. 여기에 나타난 결과는 제어된 환경에서 가능한 성능 증가의 하나의 관점을 표현한다. 다른 조건에서 결과는 다를 수 있다.

위로

워크스테이션 클라이언트 기능 성능

이 섹션은 워크스테이션 클라이언트를 사용하는 증가분 백업과 선택적 백업 클라이언트/서버 기능에 대한 측정치를 포함한다. 모든 측정치는 LAN을 넘어 데이터 플로잉으로 작성되었다. 서버는 네 개의 1GB Ethernet 어댑터로 구성되고 각 클라이언트는 한 개의 1GB Ethernet 어댑터가 있다. 이러한 여러 클라이언트 테스트는 균형이 맞추어졌으므로 모든 서버 LAN 연결은 동등하게 사용 중이었다. 즉, 이는 비록 소규모 파일을 사용하는 이러한 테스트에서 LAN은 병목현상이 아니다. 모든 통신은 표준 Ethernet 프레임(1500바이트)을 사용했다.

모든 클라이언트 기능 측정치는 각 클라이언트 플랫폼에 대해 명령행 백업/아카이브 클라이언트를 사용하여 작성되었다.

LAN 증가분 백업

증가분 백업 기능은 지정된 클라이언트 파일 시스템에서 변경된 파일을 백업하는 데 사용된다. 데이터는 클라이언트에서 LAN을 넘어 서버로 전송된 다음에 디스크에 쓰여진다. 백업 경과 시간은 파일 시스템에서 파일과 디렉토리의 총 개수에 따라 달라진다. 즉, 이는 신규의 변경되거나 삭제된 파일의 수와 백업된 파일의 크기 뿐만 아니라 다른 요인이다. 백업되어야 하는 파일과 디렉토리가 결정되면 대용량 파일 처리량은 일반적으로 스토리지 디바이스 또는 네트워크 대역폭에 따라 제한되고, 소규모 파일 처리량은 일반적으로 클라이언트에서 파일 열기/닫기 조작 및 서버에서 데이터베이스 처리에 따라 제한된다. 따라서, 이 섹션의 측정치는 클라이언트 파일 시스템에서 변경된 파일과 이러한 변경을 통해 Tivoli Storage Manager 서버 데이터베이스를 업데이트하는 것의 성능을 판별하는 시간에 집중하여 10KB 파일 워크로드만으로 수행되었다. Tivoli Storage Manager는 다른 상황에 최적화된 몇 가지의 메소드를 사용하여 증가분 백업을 수행할 수 있다.

memoryefficientbackup no 옵션을 사용하는 증가분 백업은 Tivoli Storage Manager 클라이언트가 파일과 디렉토리 목록을 수신하고 백업되는 파일 시스템을 위해 Tivoli Storage Manager 서버로부터 속성을 수신하는 것을 의미하므로, 어느 오브젝트가 신규이거나 변경되며 반드시 백업해야 하는지 그리고 어느 오브젝트가 삭제되어 만기되어야 하는지 판별하기 위해 비교될 수 있다. 저널 기반 증가분 백업은 Tivoli Storage Manager 클라이언트가 신규이거나 변경되고 백업되어야 하는 자체 오브젝트 목록과 삭제되고 만기되어야 하는 오브젝트를 유지보수하는 것을 의미한다. 저널 기반 증가분 백업이 인벤토리 데이터에 대한 서버를 쿼리하지 않고 백업되는 파일 시스템을 스캔하지 않기 때문에, 대개 memoryefficientbackup no 옵션을 사용하는 증가분 백업보다 더 빠르다. 하지만, 많은 클라이언트가 동시에 데이터를 백업하는 중인 경우 Tivoli Storage Manager 서버 데이터베이스가 병목현상이 될 수 있다. 이로 인해 저널 기반 증가분 백업이 전체 증가분 백업보다 더 빠르지 않을 수 있다.

다양한 옵션이 있는 증가분 백업의 결과는 그림 2에 표시된다. 테스트 매개변수는 표 2에 있음을 참고하자. SSD를 사용하면 비저널 기반 백업을 사용하여 증가분 백업에 70퍼센트 처리량 증가를 초래했다. 저널 기반 백업은 RAID 5 어레이에 구성된 SSD를 사용하여 놀라운 229퍼센트 증가를 나타냈다. RAID 보호의 추가 혜택을 보유하는 것은 일반적으로 경험하는 대로 성능을 저하시키지 않았다.

클라이언트 중복 제거를 사용하는 LAN 선택 백업

선택적 백업 기능은 지정된 클라이언트 파일 시스템에서 모든 파일과 디렉토리의 하나의 복사본을 백업하는 데 사용된다. 데이터는 클라이언트로부터 LAN을 넘어 서버로 전송된 다음에 디스크에 쓰여진다. 백업 처리량은 처리된 파일의 크기에 따라 다르다. 대용량 파일 처리량은 일반적으로 스토리지 디바이스 또는 네트워크 대역폭에 따라 제한되고, 소규모 파일 처리량은 일반적으로 서버에서 클라이언트 및 데이터베이스 처리에서 파일 열기/닫기 조작에 따라 제한된다.

그림 3은 클라이언트 측 중복 제거를 사용하는 선택적 백업의 결과를 보여준다. 이 경우에("0,1"로 레이블됨), 중복 청크에 대한 검사는 각각 청크가 고유한 것을 찾고, 검사한 후에 데이터는 서버로 전송되어야 한다. 두 번째 케이스("100, 2")에서 중복 청크에 대한 검사는 각각 청크가 중복되는 것을 찾고, 검사한 후에 데이터가 서버로 전송되지 않아도 된다. 하지만, 청크에 대한 데이터베이스 정보는 업데이트되어야 한다.

두 번째 케이스도 비활성화되도록 업데이트된 각 파일의 기존 버전과 삽입된 새 버전이 필요하다. 필수적으로 두 번째 케이스는 데이터베이스 작업을 더 많이 수반하며, 이는 데이터베이스 디스크가 병목현상일 때 서버에 압박이 더 많아져 차이가 더 커지는 것을 의미한다.

처리량은 서버로 전송되거나 서버에서부터 수신되는 데이터 양에 따라 달라짐을 참고하자. 중복 제거를 사용하는 테스트가 중복 제거를 사용하지 않는 테스트보다 훨씬 더 적게 전송될 수 있으므로, 처리량은 경과 시간이 동등한 경우에도 훨씬 더 낮을 수 있다. 이러한 이유로 인해 처리량보다 이러한 테스트들 사이에 경과 시간의 차이에 주목하는 것이 더 유용하다.

그림 3과 같이 클라이언트측 중복 제거를 사용하는 최초의 선택적 백업의 경과 시간은 JBOD SSD 볼륨을 사용할 때보다 20퍼센트 낮아졌고, DS8100 볼륨을 사용하는 것과 비교할 때 RAID 5 SSD 볼륨에 데이터베이스 디렉토리를 둘 때보다 19퍼센트 낮아졌다. 클라이언트측 중복제거를 사용하는 두 번째 선택적 백업의 경과 시간은 하나의 JBOD SSD 볼륨을 사용하면 57퍼센트 낮아졌고, DS8100 볼륨과 비교하면 RAID 5 SSD 볼륨을 활용할 때보다 54퍼센트 낮아졌다. 두 번째 선택적 백업 테스트 도중에 실행된 초당 데이터베이스 I/O 연산(IOPS)의 평균 수는 DS8100 볼륨에서 1200, JBOD SSD 볼륨에서 2,900 및 RAID 5 SSD 볼륨에서 2,660이었다. 이러한 결과는 중복 데이터가 있을 때 선택적 백업에 대한 SSD의 엄청난 혜택이 나타난다.

위로

서버 기능 성능

이 섹션은 인벤토리 만기, 데이터베이스 업그레이드 및 데이터베이스 백업을 비롯한 서버 기능의 측정치를 포함한다. 이 측정의 의도는 DS8100 볼륨, JBOD SSD 볼륨 및 RAID 5 SSD 볼륨에서 하나의 데이터베이스 디렉토리를 사용하는 Tivoli Storage Manager 서버 데이터베이스 사이에 성능을 비교하는 것이다.

인벤토리 만기

인벤토리 만기 기능은 클라이언트 백업으로 데이터베이스 참조를 제거하거나 Tivoli Storage Manager 정책 정의에 따라 서버 스토리지로부터 오브젝트를 아카이브하는 데 사용된다.

Tivoli Storage Manager 서버는 병렬로 여러 인벤토리 만기 프로세스를 실행하는 기능을 포함하며, 이는 내재된 데이터베이스 성능이 충분하다면 엄청나게 늘어난 처리량을 제공할 수 있다. 인벤토리 만기는 무작위 데이터베이스 I/O의 대용량이 필요하다. 그리고, 해당하는 네트워크나 스토리지 풀 데이터 I/O가 없으므로 인벤토리 만기의 성능은 메타데이터 데이터베이스 성능으로 거의 완전히 판별된다. 데이터베이스 성능은 서버 프로세서 속도, 서버 메모리 크기, 데이터베이스 및 활성 로그 디스크 서브시스템 성능 및 데이터베이스 페이지 내에서 데이터 행의 구성에 따라 다르다. 특히 중요한 것은 쓰기 캐시가 사용된 서브시스템을 사용하는 디스크 서브시스템 성능이 데이터베이스 성능을 개선할 수 있다는 점이다.

DS8100 볼륨이 열 개 프로세스로 IOPS 병목현상이 될 때, 인벤토리 만기 처리량은 JBOD SSD 볼륨으로 43퍼센트 더 빨라졌고 RAID 5 SSD 볼륨에서 44퍼센트 더 빨라졌다. 이러한 열 개 프로세스 인벤토리 만기 테스트 도중에 실행된 IOPS의 평균 숫자는 DS8100 볼륨에서 1,840이었고, JBOD SSD 볼륨에서 3,180 및 RAID5 볼륨에서 3,230이었다.

데이터베이스 업그레이드

데이터베이스 업그레이드 유틸리티는 Tivoli Storage Manager 서버 데이터베이스를 Tivoli Storage Manager 5.5 서버에 사용되는 기본 데이터베이스 형식으로부터 Tivoli Storage Manager 6.2 서버에 사용되는 DB2 데이터베이스로 업그레이드하는 데 사용되었다. 이는 데이터베이스 형식이 완전히 다르기 때문에 긴 조작이다. 네트워크 메소드는 가장 신속한 메소드이고 중간 스토리지 자원이 필요하지 않기 때문에 업그레이드에 사용되었다. 이러한 테스트의 경우, 기존 데이터베이스와 새 데이터베이스 둘 다 동일한 시스템에 있다. 데이터베이스가 새 데이터베이스 구조로 이동되면서, 데이터의 유효성은 새 데이터베이스에서 강제되는 제한조건에 대해 검사한다. 업그레이드 유틸리티는 데이터베이스에서 자동으로 일부 오류를 정정한다.

업그레이드 프로세스는 중요한 프로세서, 메모리 및 I/O 자원이 필요하다. 동일한 데이터베이스의 경우, 업그레이드 프로세스는 새 데이터베이스에 더 빠른 프로세서와 더 빠른 디스크 스토리지를 사용할 때 일반적으로 경과 시간을 더 적게 요구할 것이다. 업그레이드 유틸리티가 페이지 형식으로 기존 서버 데이터베이스로부터 데이터를 순차적으로 읽기 때문에, 기존 데이터베이스는 병목현상이 될 가능성이 낮고 기존 데이터베이스에 더 빠른 하드웨어를 제공하기에 유용하지 않다. 비록 Tivoli Storage Manager 서버 데이터베이스가 100개 이상의 테이블로 구성된다고 하더라도, 실제로 많은 데이터베이스 행으로 된 테이블이 두 개 또는 세 개가 있다. 그러므로 대부분의 작업을 실행할 몇 가지의 스레드만 있다. 이는 겨우 몇 가지 프로세서만 필요하다는 것을 의미하며 프로세서를 더 추가해도 경과 시간이 줄어들지 않을 것이다.

이러한 테스트에서 업그레이드된 Tivoli Storage Manager 서버 데이터베이스는 여러 개의 증가분 백업 버전과 아카이브로 128개의 노드에 대한 정보가 포함되었다. 저장된 오브젝트의 총 수는 약 6천만 개이며, 모두 무작위 디스크 스토리지 풀에 저장된다. 백업 및 아카이브 프로세스는 동시에 실행되었으므로 기존 데이터베이스는 하나의 테이블로 할당되는 페이지의 긴 순서 없이 구성되었다.

위의 그림 5와 같이 데이터베이스 업그레이드 처리량은 JBOD SSD 볼륨을 사용할 때 100퍼센트 더 빨라졌고 DS8100 볼륨에서 디렉토리를 저장하는 것과 비교하면 RAID 5 SSD 볼륨을 사용할 때 90퍼센트 더 빨라졌다. 업그레이드 테스트 도중에 실행된 IOPS의 평균 숫자는 30KB 정도의 평균 I/O 크기로 DS8100 볼륨에서 790이었고, JBOD SSD 볼륨에서 1,710이었으며 RAID 5 SSD 볼륨에서 1,630이었다. 하나의 DS8100 볼륨은 업그레이드 조작에 대한 병목현상이었다. 하나 이상의 DS8100 볼륨을 사용하면 데이터베이스 업그레이드 처리량을 개선할 가능성이 높은 반면, JBOD SSD 볼륨이나 RAID 5 SSD 볼륨은 병목현상이 아니었다.

데이터베이스 백업

데이터베이스 백업 기능은 복구 용도로 서버 스토리지에서 Tivoli Storage Manager 데이터베이스의 복사본을 만드는 데 사용되었다. 이러한 테스트에서 Tivoli Storage Manager 서버 데이터베이스가 여러 증가분 백업 버전과 아카이브로 128개 노드에 대한 정보를 포함했다. 저장된 오브젝트의 총 수는 약 6천만 개이며, 모든 오브젝트는 무작위 디스크 스토리지 풀에 저장된다. 이 실험을 위해 서버에서 활성된 중복 제거는 없었다.

아래 그림 6과 같이 전체 데이터베이스 백업 처리량은 Tivoli Storage Manager 서버 데이터베이스의 위치에 관계없이 모든 테스트에 필수적으로 동일했다. IBM High IOPS SSD 어댑터 순차적 읽기 처리량이 매우 빨랐기 때문에 다른 컴포넌트들이 이 조작의 병목현상이었다.

위로

결론

여기에 나타난 결과는 표준 HDD 디스크 어레이와 비교하면 메타데이터 디렉토리 스토리지에 사용될 때 SSD가 Tivoli Storage Manager 성능에 미칠 수 있는 방대한 영향을 보여준다. Tivoli Storage Manager는 백업되는 파일에 대한 메타데이터의 자세한 세트를 유지보수해야 한다. 데이터베이스로 쿼리 또는 업데이트가 중요해질 때 이 데이터베이스는 IO 병목현상이 된다. SSD는 데이터베이스 서버에서 IO 병목 현상을 제거하므로 RAID5 결함 허용 구성에서조차도 엄청난 처리량 증가를 제공한다. 증가분 백업 및 선택적 백업은 각각 최대 229퍼센트와 50퍼센트의 증가를 보여주었다. 인벤토리 만기 및 데이터베이스 업그레이드는 엄청난 처리량 증가도 경험했다.

참고자료

교육

• IBM Solid State storage technology는 디스크 또는 테이프를 돌리는 것이 아니라 대용량 스토리지에 메모리 유형 디바이스를 사용한다.
  
  
• IBM Solid State Storage PCIe Adapters는 가장 앞선 NAND 클러스터링 기술이다.
  
  
• Tivoli Storage Manager는 광범위한 스토리지 관리 기능을 제공한다.
  
  
• Fusion IO는 고체 상태 기술 및 고성능 I/O 솔루션을 제공한다.
  
  

토론

• IBM Tivoli Storage Management 포럼에 참여하자.
  
  

필자소개

아티클 순위

의견

위로

목차

• 소개
• 혁신(disruptive) 기술
• IBM Tivoli Storage Manager
• 하드웨어 및 소프트웨어 세부사항
• 워크스테이션 클라이언트 기능 성능
• 서버 기능 성능
• 결론
• 참고자료
• 필자소개
• 의견