성능 최적화 계획 가이드 - dell emc...networker 소프트웨어는 전체 데이터...

EMC® NetWorker®

릴리즈 8.0

성능 최적화 계획 가이드P/N 300-013-559

수정 버전 02

EMC NetWorker 릴리즈 8.0 성능 최적화 계획 가이드2

Copyright © 2000- 2012 EMC Corporation. All rights reserved. Published in the USA.

발행: 2012년 8월

본 문서의 정보는 발행일 현재 정확한 것으로 간주되며 모든 정보는 예고 없이 변경될 수 있습니다.

본 문서의 정보는 "있는 그대로" 제공됩니다. EMC CORPORATION은 본 문서의 정보와 관련하여 어떠한 진술이나 보증도 하지 않으며, 특히 상품성이나 특정 목적을 위한 적합성에 대하여 어떠한 묵시적인 보증도 부인합니다. 본 문서에 설명된 EMC 소프트웨어를 사용, 복사 및 배포하려면 해당 소프트웨어 라이센스가 필요합니다.

EMC2, EMC 및 EMC 로고는 미국 및 기타 국가에서 EMC Corporation의 등록 상표 또는 상표입니다. 본 문서에 사용된 기타 모든 상표는 해당 소유주의 자산입니다.

사용 중인 제품군에 대한 최신 규제 관련 문서를 보려면 EMC 온라인 지원 웹 사이트의 기술 문서 및 권장 사항 섹션으로 이동하십 시오.

목차

머리말

제 1 장 개요

구성 ........................................................................................................... 10 NetWorker 데이터 흐름............................................................................... 10

제 2 장 NetWorker 환경 사이징

교육 과정 구성 ........................................................................................... 14백업 환경 성능 기대치 확인.................................................................. 14필요한 백업 기대치 확인 ...................................................................... 15

시스템 구성 요소........................................................................................ 15시스템 .................................................................................................. 16메모리 요구 사항 .................................................................................. 17시스템 버스 요구 사항.......................................................................... 18스토리지 고려 사항 .............................................................................. 20스토리지 성능 요구 사항 ...................................................................... 21네트워크 .............................................................................................. 26타겟 디바이스 ...................................................................................... 26구성 요소 70% 규칙 ............................................................................. 27

NetWorker 환경의 구성 요소....................................................................... 27데이터 영역 .......................................................................................... 28NetWorker Management Console .......................................................... 28콘솔 데이터베이스 ............................................................................... 29NetWorker Server .................................................................................. 30NetWorker storage node........................................................................ 32NetWorker 클라이언트.......................................................................... 32NetWorker 데이터베이스 ...................................................................... 33선택적 NetWorker 애플리케이션 모듈 .................................................. 33가상 환경.............................................................................................. 33NetWorker 중복 제거 노드 .................................................................... 33

복구 성능 요소 ........................................................................................... 34 접속 및 병목 현상....................................................................................... 34

NetWorker 데이터베이스 병목 현상...................................................... 39

제 3 장 설정 조정

NetWorker 병렬 처리 최적화....................................................................... 42서버 병렬 처리 수 ................................................................................. 42클라이언트 병렬 처리 수 ...................................................................... 42그룹 병렬 처리 수 ................................................................................. 43멀티플렉싱 ........................................................................................... 43

파일 시스템 밀도........................................................................................ 44 디스크 최적화 ............................................................................................ 45 디바이스 성능 튜닝 방법............................................................................ 45

입력/출력 전송 속도............................................................................. 45내장된 압축 .......................................................................................... 45드라이브 스트리밍 ............................................................................... 45디바이스 로드 밸런싱........................................................................... 46

EMC NetWorker 릴리즈 8.0 성능 최적화 계획 가이드 3

목차

디스크 드라이브 조각화 ....................................................................... 46 네트워크 디바이스..................................................................................... 47

Fiber Channel 지연................................................................................ 47DataDomain.......................................................................................... 48AFTD 디바이스 타겟 및 최대 세션 ......................................................... 49가상 디바이스 드라이브 수와 물리적 디바이스 드라이브 수................ 50

네트워크 최적화 ........................................................................................ 51고급 구성 최적화 .................................................................................. 51운영 체제 TCP 스택 최적화 ................................................................... 51고급 튜닝.............................................................................................. 52네트워크 지연 ...................................................................................... 52이더넷 이중화 ...................................................................................... 54방화벽 .................................................................................................. 54점보 프레임 .......................................................................................... 54정체 알림.............................................................................................. 55TCP 버퍼 ............................................................................................... 55NetWorker 소켓 버퍼 크기 .................................................................... 56IRQ 밸런싱 및 CPU 선호도 .................................................................... 57인터럽트 조절 ...................................................................................... 58TCP 이동 ............................................................................................... 58이름 확인.............................................................................................. 58

스토리지 최적화 ........................................................................................ 59NetWorker 서버 및 스토리지 노드 디스크 쓰기 지연............................. 59

제 4 장 성능 테스트

증상 확인 ................................................................................................... 62 성능 모니터링 ............................................................................................ 62 일반 FTP 테스트를 사용하여 병목 현상 확인 .............................................. 63 dd를 사용하여 설정 성능 테스트................................................................ 63 bigasm 및 uasm을 사용하여 디스크 성능 테스트 ....................................... 64

bigasm 지침.......................................................................................... 64uasm 지침 ............................................................................................ 64

4 EMC NetWorker 릴리즈 8.0 성능 최적화 계획 가이드

머리말

제품군 향상을 위한 노력의 일환으로 EMC는 소프트웨어 및 하드웨어의 수정 버전을 정기적으로 릴리즈합니다. 따라서 이 문서에서 설명하는 일부 기능은 현재 사용 중인 소프

트웨어 또는 하드웨어의 모든 버전에서 지원되지 않을 수도 있습니다. 제품 기능에 대한 최신 정보는 제품 릴리즈 노트를 참조하십시오.

제품이 올바르게 작동하지 않거나 이 문서에 설명된 대로 작동하지 않는 경우 EMC 담당자에게 문의하십시오.

참고: 이 문서에서 설명하는 내용은 발행 당시를 기준으로 정확합니다. 이 문서의 새 버전이 EMC 온라인 지원 웹 사이트에 릴리즈될 수 있습니다. EMC 온라인 지원 웹 사이트에

서 이 문서의 최신 버전을 사용하고 있는지 확인하십시오.

목적

이 문서에서는 EMC Consistency Group(ConGroup)을 구성 및 사용하는 방법을 설명합 니다.

대상

이 문서는 호스트 시스템 관리자, 시스템 프로그래머 또는 ConGroup 관리를 담당하는 운영자를 대상으로 합니다.

관련 설명서

5페이지의 표 1에는 추가 정보를 제공하는 EMC 문서가 나와 있습니다.

표 1 추가 정보를 제공하는 EMC 문서 (1/2페이지)

가이드 이름 설명

NetWorker 관리 가이드 NetWorker 소프트웨어를 구성 및 유지 보수하는 방법에 대해 설명합니다.

NetWorker 설치 안내서 지원되는 모든 운영 체제에서 클라이언트, 스토리지 노드 및 서버용 NetWorker 소프트웨어를 설치, 제거 및 업데이트하는 방법에 대한 정보를 제공합니다.

NetWorker 클러스터 설치 가이드 클러스터 서버와 클라이언트에서 NetWorker 소프트웨어를 설치 및 관리하는 방법에 대한 정보를 제공합니다.

NetWorker 라이센스 안내서 NetWorker 제품 및 기능의 라이센스 등록에 대한 정보를 제공합니다.

NetWorker 릴리즈 노트 최신 NetWorker 소프트웨어 릴리즈의 새 기능, 변경 사항, 해결된 문제, 알려진 제한 사항, 환경 및 시스템 요구 사항에 대한 정보를 제공합니다.

NetWorker 명령 참조 가이드 NetWorker 명령 및 옵션에 대한 참조 정보를 제공합니다.

NetWorker 오류 메시지 가이드 일반적인 NetWorker 오류 메시지에 대한 정보를 제공합니다.

NetWorker 재해 복구 가이드 NetWorker 서버, 스토리지 노드 및 클라이언트의 복구 및 재해 준비에 대한 정보를 제공합니다.


머리말

이 문서에 사용된 표기법

특별한 고지 사항이 있을 경우 다음과 같은 표기법을 사용하였습니다.

알림은 부상과 관련되지 않은 상황을 다루는 데 사용됩니다.

참고: 참고는 중요하지만 위험하지는 않은 정보를 나타냅니다.

NPG(NetWorker Procedure Generator) NPG는 고객, 지원 센터 및 현장에서 많이 수행하는 작업에 대해 사용자 중심의 세부적인 수행 단계를 생성하는 데 사용할 수 있는 실행 가능한 다운로드입니다.

NetWorker 라이센스 안내서 NetWorker 및 해당 모듈의 라이센스 등록에 대한 정보를 제공합니다.

NetWorker 소프트웨어 호환성 가이드 다음과 같은 소프트웨어 제품에 대해 지원되는 클라이언트, 서버 및 스토리지 노드 운영 체제의 목록이 나와 있습니다. NetWorker 및 NetWorker 애플리케이션의 모듈과 옵션(중복 제거 및 가상화 지원 포함), AlphaStor, Data Protection Advisor 및 HomeBase.

NetWorker Data Domain 중복 제거 디바이스 통합 가이드

NetWorker 환경에서 데이터 중복 제거 백업 및 스토리지를 위한 Data Domain 디바이스 사용에 대한 계획 및 구성 정보를 제공합니다.

NetWorker Avamar 통합 가이드 NetWorker 환경에서 Avamar를 사용하기 위한 계획 및 구성 정보를 제공합니다.

EMC NetWorker Management Console 온라인 도움말

NetWorker Management Console 및 NetWorker Administration 창에서 수행하는 일상적인 관리 작업에 대해 설명합니다. 도움말을 보려면 기본 메뉴에서 도움말을 클릭합니다.

EMC NetWorker User Online Help NetWorker User 프로그램은 Windows 클라이언트 인터페이스 입니다. Windows 클라이언트 인터페이스인 NetWorker User 프로그램을 사용하여 NetWorker 서버에 접속한 후 네트워크를 통해 파일을 백업, 복구, 아카이빙 및 검색하는 방법에 대해 설명합니다.

기술 노트/백서 기술 노트와 백서에서는 중요한 비즈니스 문제나 요구 사항에 적용되는 제품의 세부 기술 측면에 대해 설명합니다. 기술 노트 및 백서 유형에는 기술 및 비즈니스 고려 사항, 응용 기술, 상세 검토, Best Practice 계획 등이 있습니다.

표 1 추가 정보를 제공하는 EMC 문서 (2/2페이지)

가이드 이름 설명


머리말

표기법

이 설명서에서는 다음과 같은 유형의 표기법을 사용합니다.

일반• 인터페이스 요소의 이름(예: 창, 대화 상자, 버튼, 필드 및 메뉴의 이름)

• 리소스, 속성, 풀, 부울 표현식, 버튼, DQL 문, 키워드, 절, 환경 변수, 함수, 유틸리티의 이름

• URL, 경로 이름, 파일 이름, 디렉토리 이름, 컴퓨터 이름, 링크, 그룹, 서비스 키, 파일 시스템, 알림

굵은 글꼴

• 인터페이스 요소의 이름(예: 창, 대화 상자, 버튼, 필드 및 메뉴의 이름)

• 사용자가 명확하게 선택하거나, 클릭하거나, 누르거나, 입력하는 항목

기울임꼴• 본문 중 참조되는 출판물의 전체 제목

• 강조(예: 새로운 용어)

• 변수

Courier

• 시스템 출력(예: 오류 메시지 또는 스크립트)

• URL, 전체 경로, 파일 이름, 확인 메시지 및 구문(본문 밖에 표시될 때)

Courier 굵은 글꼴

Courier 기울임꼴• 명령줄의 변수

• 사용자 입력 변수

< >

[ ]

|

{ }

...

지원 정보

EMC 지원, 제품 및 라이센스 정보는 다음과 같이 확인할 수 있습니다.

제품 정보 — EMC 제품에 대한 설명서, 릴리즈 노트, 소프트웨어 업데이트 또는 자세한 정보는 다음의 EMC 온라인 지원 웹 사이트에 있습니다.

http://support.emc.com

기술 지원 — EMC 온라인 지원 웹 사이트로 이동하여 서비스 센터를 클릭합니다. EMC 기술 지원에 문의할 수 있는 여러 옵션이 나타납니다. 서비스 요청을 개설하려면 유효한 지원 계약이 있어야 합니다. 유효한 지원 계약을 체결하는 방법에 대한 자세한 내용이나 계정에 대한 질문은 EMC 영업 담당자에게 문의하십시오.

제안 사항

여러분의 제안 사항은 사용자 문서의 정확도, 구성 및 전반적인 품질을 지속적으로 향상시키는 데 도움이 됩니다. 다음 주소로 이 문서에 대한 여러분의 의견을 보내주십시오.

[email protected]

다음에 대해 절차에 관계 없이 본문에 사용:

명령, 데몬, 옵션, 프로그램, 프로세스, 서비스, 애플리케이션, 유틸리티, 커널, 알림, 시스템 호출, man 페이지의 이름에 대해 절차에 관계없이 본문에 사용

다음에 대해 절차에 따라 수행하는 경우 사용:

다음에 대해 모든 텍스트에 사용(절차에 따라 수행되는 경우 포함):

다음을 나타내기 위해 사용됨:

특정 사용자 입력(예: 명령)에 사용됨

다음에 대해 절차에 따라 수행하는 경우 사용:

사용자가 입력하는 매개 변수 또는 변수 값은 꺾쇠 괄호로 표시합니다.

선택적 값은 대괄호로 표시합니다.

세로 막대는 대체 선택 항목을 나타냅니다(막대는 "또는"을 의미함).

중괄호는 사용자가 지정해야 하는 컨텐츠(x, y 또는 z)를 나타냅니다.

줄임표는 예제에서 생략된 중요하지 않은 정보를 의미합니다.


http://support.emc.com

머리말


1장

개요

NetWorker 소프트웨어는 전체 데이터 영역에 있는 많은 양의 복잡한 데이터에 대한 고속 백업 및 복구 작업에 맞게 최적화된 네트워크 스토리지 관리 애플리케이션입니다. 이 가이드에서는 무중단 성능 튜닝 옵션을 소개합니다. 성능을 예상만큼 발휘하지 못하

는 물리적 디바이스도 있을 수 있지만 일반적으로 물리적 구성 요소를 더 우수한 성능의 디바이스로 교체하는 경우 다른 구성 요소에서 병목 현상이 발생합니다. 이 설명서에서

는 기존 환경의 운영 중단을 최소화하면서 NetWorker 성능 튜닝을 수행하는 방법을 설명

합니다. 즉, 기능을 미세하게 튜닝함으로써 같은 하드웨어 세트를 사용하여 성능을 향상

시키고 관리자가 다음 작업을 수행할 수 있도록 지원합니다.

◆ 데이터 전송 관련 기본 사항 이해

◆ 요구 사항 확인

◆ 병목 현상 발생 부분 파악

◆ NetWorker 성능 최적화 및 튜닝

이 장은 다음 섹션으로 구성됩니다.

◆ 구성 ....................................................................................................................... 10◆ NetWorker 데이터 흐름 ........................................................................................... 10

개요 9

개요

구성이 가이드는 다음 장으로 구성됩니다.

◆ 제2장 "NetWorker 환경 사이징"에서는 요구 사항을 확인하는 방법에 대해 자세히 설명합니다.

◆ 제3장 "설정 조정"에서는 백업 환경을 튜닝하여 백업을 최적화하고 성능을 복원하

는 방법에 대해 자세히 설명합니다.

◆ 제4장 "성능 테스트"에서는 사용 가능한 툴을 통해 병목 현상을 테스트 및 파악하는 방법에 대해 자세히 설명합니다.

NetWorker 데이터 흐름10페이지의 그림 1 및 11페이지의 그림 2에는 EMC® NetWorker 데이터 영역에 있는 구성 요소의 백업 및 복구 데이터 흐름이 나와 있습니다.

그림 1 및 그림 2의 다이어그램은 일부 프로세스 간 통신만 표시하도록 간소화되었으며, 이 외에도 기타 다양한 백업 및 복구 데이터 흐름 구성을 사용할 수 있습니다.

그림 1 NetWorker 백업 데이터 흐름


개요

그림 2 NetWorker 복구 데이터 흐름

NetWorker 데이터 흐름 11

개요


2장

NetWorker 환경 사이징

이 장에서는 백업 및 시스템 요구 사항을 가장 효율적으로 확인하는 방법을 설명합니다. 첫 단계로는 환경을 파악해야 합니다. 성능 문제는 하드웨어 또는 환경 문제로 인해 발생

하는 경우가 많습니다. NetWorker 소프트웨어에서 예상할 수 있는 최적의 성능을 확인하

려면 전체 백업 데이터 흐름을 이해하는 것이 중요합니다.

이 장에서 다루는 내용은 다음과 같습니다.

◆ 교육 과정 구성 ....................................................................................................... 14◆ 시스템 구성 요소.................................................................................................... 15◆ NetWorker 환경의 구성 요소................................................................................... 27◆ 복구 성능 요소 ....................................................................................................... 34◆ 접속 및 병목 현상................................................................................................... 34

NetWorker 환경 사이징 13


교육 과정 구성이 섹션에서는 백업 환경 성능 기대치 및 필수 백업 구성에 대해 설명합니다.

백업 환경 성능 기대치 확인

아래에는 백업 환경 사이징 관련 고려 사항이 나와 있습니다.

◆ NetWorker 서버, 스토리지 노드 및 클라이언트를 비롯한 백업 환경 성능 기대치를 설정하기 전에 네트워크 및 스토리지 인프라스트럭처 정보를 검토합니다.

◆ 각 클라이언트에 대해 RTO(복구 시간 목표)를 검토 및 설정합니다.

◆ 각 NetWorker 클라이언트에 대해 백업 윈도우를 결정합니다.

◆ 전체 및 증분 백업 중에 각 클라이언트에 대해 백업할 데이터의 양을 목록으로 작성

합니다.

◆ 각 클라이언트의 데이터 증가율을 확인합니다.

◆ 클라이언트 탐색 및 보존 정책 요구 사항을 확인합니다.

사용하는 디바이스 및 환경을 고려하여 성능 기대치를 정확하게 파악하기란 쉽지가 않습니다. 설정의 병목 현상을 파악하고 그에 따라 성능 기대치를 적절하게 설정해야 합니다.

아래에는 병목 현상을 파악하고 성능 기대치를 정의하는 데 도움이 되는 몇 가지 제안이 나와 있습니다.

◆ 다이어그램 생성 ◆ 모든 시스템, 스토리지, 네트워크 및 타겟 디바이스 구성 요소의 목록 작성 ◆ 데이터 경로 목록 작성 ◆ 각 클라이언트의 데이터 경로에서 병목 현상 구성 요소 파악

34페이지의 "접속 및 병목 현상"에는 NetWorker 환경에서 발생 가능한 병목 현상의 예가 나와 있습니다.

각 NetWorker 클라이언트에 대해 발생할 수 있는 다운타임을 확인하는 것이 매우 중요합

니다. 다운타임에 따라 RTO가 결정됩니다. 각 NetWorker 클라이언트에 대해 RTO를 검토

하여 문서로 작성합니다.

각 클라이언트의 백업 윈도우를 결정하려면 다음을 따르십시오.

1. 각 NetWorker 클라이언트에 대해 사용 가능한 백업 윈도우를 확인합니다.

2. 전체 또는 증분 백업에 대해 클라이언트에서 백업해야 하는 데이터의 양을 목록으로 작성합니다.

3. 각 NetWorker 클라이언트의 평균 일별/주별/월별 데이터 증가를 목록으로 작성합

니다.



필요한 백업 기대치 확인

아래에는 해당 환경에 요구되는 백업 구성 기대치를 확인하는 방법이 나와 있습니다.

◆ 기존 백업 정책을 확인하여 정책이 각 클라이언트의 RTO를 충족하는지 파악합니다.

◆ 수집된 정보를 기준으로 각 NetWorker 클라이언트의 백업 윈도우를 예상합니다.

◆ 다음 매개 변수를 기준으로 개별 NetWorker 클라이언트 그룹의 구성을 결정합니다.

• 백업 윈도우 • 비즈니스 중요성

• 물리적 위치 • 보존 정책

◆ 각 클라이언트에 대해 생성된 백업을 사용하여 RTO를 충족할 수 있는지 확인합니다.

허용 가능한 다운타임이 짧을수록 백업 비용이 높아집니다. 허용 가능한 다운타임이 매우 짧은 경우에는 전체 백업 및 여러 증분 백업에서 백업 이미지를 구성하지 못할 수도 있습니다. 따라서 전체 백업 빈도를 높여야 할 수 있으므로 백업 윈도우가 더 길어집

니다. 그러면 네트워크 대역폭 요구 사항도 증가합니다.

시스템 구성 요소모든 백업 환경에서는 병목 현상이 발생합니다. 경우에 따라 병목 현상이 빠르게 사라

질 수도 있지만, 병목 현상 자체에 따라 시스템에서 달성할 수 있는 최대 처리량이 결정

됩니다. 백업 및 복원 작업의 최대 속도는 백업 체인에서 가장 느린 구성 요소의 속도에 해당합니다.

성능 문제는 데이터 영역의 하드웨어 디바이스 때문에 발생하는 경우가 많습니다. 이 가이드에서는 하드웨어 디바이스가 올바르게 설치 및 구성되어 있다고 가정합니다.

이 섹션에서는 요구 사항을 확인하는 방법을 설명합니다. 예를 들어,

◆ 이동해야 하는 데이터의 양◆ 백업 윈도우의 정의 ◆ 필요한 드라이브의 수 ◆ 필요한 CPU의 수

백업 네트워크의 디바이스는 4가지 구성 요소 유형으로 그룹화할 수 있습니다. 이러한 그룹은 디바이스의 사용 방법 및 사용 위치를 기준으로 합니다. 일반적인 백업 네트워크

에 있는 4가지 구성 요소는 다음과 같습니다.

◆ 시스템

◆ 스토리지

◆ 네트워크

◆ 타겟 디바이스

시스템 구성 요소 15


시스템

시스템 구성에서 성능에 영향을 주는 구성 요소는 다음과 같습니다.

◆ CPU

◆ 메모리

◆ 시스템 버스(사용 가능한 최대 입출력 대역폭을 결정함)

CPU 요구 사항

필요한 최적의 CPU 수를 결정합니다. 소스 디바이스에서 타겟 디바이스로 데이터 1MB를 이동하는 데 5MHz가 필요하다고 가정해 보겠습니다. 예를 들어 초당 100MB의 속도

로 로컬 테이프 드라이브로 백업하는 NetWorker 서버 또는 스토리지 노드에 1GHz의 CPU 성능이 필요한 경우 데이터 이동에 필요한 CPU는 다음과 같습니다.

◆ 데이터를 네트워크에서 NetWorker 서버 또는 스토리지 노드로 이동하려면 500MHz가 필요합니다.

◆ 데이터를 NetWorker 서버 또는 스토리지 노드에서 백업 타겟 디바이스로 이동하

려면 500MHz가 필요합니다.

참고: 특정 CPU 유형의 1GHz를 다른 공급업체 CPU의 1GHz와 직접 비교할 수는 없습

니다.

시스템의 CPU 로드는 다양한 요소의 영향을 받습니다. 예를 들어,

◆ CPU 로드가 높다고 해서 반드시 CPU 성능이 부족한 것은 아니지만, 다른 시스템 구성 요소의 구성에 좋지 않은 영향을 줄 수는 있습니다.

◆ 드라이버:

서로 성능이 다른 여러 공급업체의 드라이버를 조사해 봅니다. 동일한 운영 체제에서 사용되며 처리량이 같은 드라이버라도 사용하는 CPU의 양은 크게 다를 수 있습 니다.

◆ 디스크 드라이브 성능:

• /nsr의 클라이언트 수가 400개 이상인 백업 서버에서 디스크 드라이브 사용량이 많으면 CPU가 60% 넘게 사용되는 경우가 많습니다. 그러나 활용도가 낮은 디스

크 스토리지에서는 /nsr에서 동일한 백업 서버의 CPU 사용량이 15% 미만이 됩

니다.

• UNIX 및 Windows에서는 권한이 부여된 모드에서 CPU 시간이 많이 소요되거나 사용자 시간보다 시스템 시간에서 CPU 로드 비율이 높은 경우 NetWorker 프로세스

가 입출력 완료를 대기 중일 가능성이 높습니다. NetWorker 프로세스가 입출력을 대기 중인 경우 병목 현상은 CPU가 아닌 NetWorker 서버를 호스팅하는 데 사용되

는 스토리지에서 발생합니다.

• Windows에서는 지연된 프로시저 호출에 시간이 오래 걸리면 디바이스 드라이버

에 문제가 있는 경우가 많습니다.

◆ 다음 분류에 따라 CPU 사용량을 모니터링합니다.

• 사용자 모드

• 시스템 모드

◆ 하드웨어 구성 요소 인터럽트가 발생하면 시스템 CPU 사용량이 많아져 성능이 저하

됩니다. 디바이스 인터럽트 수가 초당 1만 개를 초과하는 경우 디바이스를 확인하십

시오.



메모리 요구 사항

17페이지의 표 2에는 NetWorker 서버의 최소 메모리 요구 사항이 나와 있습니다. 이 요구 사항을 적용하면 메모리에서 병목 현상이 발생하지 않습니다.

표 2 NetWorker 서버에 필요한 최소 메모리

클라이언트 수 필요한 최소 메모리

페이지 파일 또는 스왑 사용량 모니터링 전용 백업 서버에서 메모리 페이징이 발생하면 백업 환경의 성능에 나쁜 영향을 줄 수 있습니다.

Windows 2003 관련 고려 사항

Windows 2003 서버와 관련된 다음 권장 사항을 고려하십시오.

◆ Windows 2003 32비트 서버는 기본적으로 커널 모드 및 애플리케이션 모드 프로세

스 둘 다에 대해 2GB 메모리를 할당합니다. 성능을 높이려면 NetWorker 소프트웨어

용으로 추가 메모리를 할당하십시오. 자세한 내용은 Microsoft 기술 자료 문서 283037을 참조하십시오.

◆ 페이징을 수행해야 하는 경우에는 Windows 서버에 설치된 물리적 RAM의 1.5배에 해당하는 최대 페이지 파일 크기를 사용하는 것이 좋습니다. 자세한 내용은 Microsoft 기술 자료 문서 2267427을 참조하십시오.

DFA(Direct File Access)용 Client Direct 속성

Client Direct 속성을 사용하여 DFA를 설정할 때는 다음 사항을 고려하십시오.

◆ 클라이언트의 CPU 성능이 DFA-DD의 향상된 성능을 활용하기에 충분한지 확인합

니다. 대부분의 경우에는 Client Direct를 사용하면 백업 성능이 크게 향상됩니다. DFA-DD 백업의 경우 각 동시 세션에 대해 약 2~10%의 CPU 로드가 더 필요합니다.

◆ DFA-DD를 사용하는 각 저장 세션에서는 최대 70MB의 메모리가 필요합니다. DFA 스트림 10개가 실행 중인 경우 모든 DFA 세션용으로 클라이언트에 필요한 메모리는 700MB입니다.

◆ DFA-AFTD로의 저장 세션에서는 Boost를 사용하여 DFA-DD에 대해 실행되는 백업에 비해 더 적은 메모리와 CPU 주기를 사용합니다. DFA-AFTD를 사용하는 저장 세션의 경우 기존의 mmd를 사용한 저장에 비해 메모리와 CPU 주기를 약간만 더 사용합

니다.

50개 미만 4GB

51~150개 8GB

151개 이상 16GB



시스템 버스 요구 사항

HBA/NIC 배치도 중요하기는 하지만 운영 체제에서 가장 중요한 구성 요소는 내부 버스

라고 할 수 있습니다. 내부 버스는 CPU, 메모리, 디스크, 네트워크 등의 내부 컴퓨터 구성 요소 간 통신 기능을 제공합니다.

버스 성능 조건: ◆ 버스 유형

◆ 데이터 너비

◆ 클록 속도

◆ 마더보드

시스템 버스 고려 사항:◆ 버스가 더 빨라진다고 해서 반드시 성능이 향상되는 것은 아닙니다.◆ 고급 시스템에는 성능 향상을 위해 버스가 여러 개 있습니다. ◆ 버스는 시스템 병목 현상의 주된 원인인 경우가 많습니다.

시스템 버스 권장 사항

서버 및 스토리지 노드 모두에 PCIeXpress를 사용하여 입출력 병목 현상의 가능성을 줄이는 것이 좋습니다.

참고: 구형 버스 또는 구형 버스용으로 최적화된 고속 구성 요소는 인터럽트를 너무 많이 생성하여 데이터 전송 중에 CPU 스파이크를 발생시킬 수 있으므로 사용해서는 안 됩니다.

PCI-X 및 PCIeXpress 고려 사항:◆ PCI-X는 반이중 양방향 64비트 병렬 버스입니다.

◆ PCI-X 버스 속도는 버스에서 가장 느린 디바이스의 속도로 제한될 수 있으므로 카드 배치 시 주의해야 합니다.

◆ PCIeXpres는 8/10 인코딩을 사용하는 전이중 양방향 직렬 버스입니다.

◆ PCIeXpress 버스 속도는 디바이스별로 확인할 수 있습니다.

◆ 고속 HBA/NIC를 저속 버스에 연결해서는 안 되며 항상 버스 요구 사항을 고려해야 합니다. PCI-X 1.0 10GbE NIC에서는 자동 패킷 삭제가 수행되어 버스 요구 사항을 충족할 수 없는 경우가 있습니다.

◆ 고속 스토리지를 저속 HBA/NIC에 연결하는 하드웨어가 있는 경우 전반적인 성능이 저하됩니다.

이상적인 구성 요소 성능 레벨에 대한 자세한 내용은 27페이지의 "구성 요소 70% 규칙"에 나와 있습니다.



버스 속도 요구 사항

아래에는 버스 속도 요구 사항이 나와 있습니다.

◆ 4Gb Fibre Channel에는 초당 425MB가 필요합니다.◆ 8Gb Fibre Channel에는 초당 850MB가 필요합니다. ◆ 10Gb Fibre Channel에는 초당 1,250MB가 필요합니다.

버스 사양

19페이지의 표 3에는 버스 사양이 나와 있습니다.

표 3 버스 사양

버스 유형 MHz 초당 MB

PCI 32비트 33 133

PCI 64비트 33 266

PCI 32비트 66 266

PCI 64비트 66 533

PCI 64비트 100 800

PCI-X 1.0 133 1,067

PCI-X 2.0 266 2,134

PCI-X 2.0 533 4,268

PCIeXpress 1.0 x 1 250

PCIeXpress 1.0 x 2 500

PCIeXpress 1.0 x 4 1,000









스토리지 고려 사항

아래에는 스토리지 구성 성능에 영향을 주는 구성 요소가 나와 있습니다.

◆ 스토리지 연결:

• 로컬 연결/SAN 연결/NAS 연결

• 스토리지 스냅샷 사용:

사용하는 스냅샷 기술에 따라 읽기 성능이 결정됩니다.

◆ 스토리지 복제:

일부 복제 기술을 사용하는 경우 쓰기 액세스에 지연이 크게 추가되므로 스토리지 액세스 속도가 느려집니다.

◆ 스토리지 유형:

• SATA 컴퓨터 버스는 하드 디스크 드라이브 및 광 드라이브와 같은 스토리지 디바

이스에 호스트 버스 어댑터를 연결하기 위한 스토리지 인터페이스입니다.

• FC(Fibre Channel)는 주로 스토리지 네트워킹에 사용되는 기가비트 속도의 네트

워크 기술입니다.

• 플래시는 컴퓨터와 기타 디지털 제품 간 데이터 전송 및 일반적인 저장에 사용되

는 비휘발성 컴퓨터 스토리지입니다.

◆ 스토리지의 입출력 전송 속도:

스토리지의 입출력 전송 속도는 여러 RAID 레벨의 영향을 받는데, 백업 서버에 가장 적합한 RAID 레벨은 RAID1 또는 RAID5입니다. 디스크로의 백업 시에는 RAID3을 사용해야 합니다.

◆ 예약된 입출력:

타겟 시스템이 입출력을 많이 사용하는 작업을 특정 시간에 수행하도록 스케줄이 지정된 경우에는 백업을 다른 시간에 실행하도록 스케줄을 지정합니다.

◆ 입출력 데이터:

• 원시 데이터 액세스는 최고 레벨의 성능을 제공하지만 향후 액세스를 위해 저장

된 데이터를 논리적으로 정렬하지 않습니다.

• 파일 수가 많은 파일 시스템의 경우 파일 시스템에서 추가 처리를 수행해야 하므

로 성능이 저하됩니다.

◆ 압축:

디스크, 운영 체제 또는 애플리케이션에서 데이터가 압축될 경우 백업 전에 데이터의 압축이 해제됩니다. 따라서 CPU에서는 파일을 다시 압축하기 위한 시간이 필요하며 이로 인해 디스크 속도가 저하됩니다.



스토리지 성능 요구 사항

NetWorker 데이터를 호스팅하는 데 사용되는 파일 시스템(/nsr)은 네이티브 파일 시스템

으로, 기본 운영 체제에 대한 운영 체제 공급업체의 지원을 받으며 Posix를 완벽하게 준수합니다.

이 단원에 설명되어 있는 IOPS로 측정되는 스토리지 성능 요구 사항이 충족되지 않으면, NetWorker Server 성능이 저하되고 짧은 시간 동안 응답하지 않게 될 수 있습니다.

스토리지 성능이 적절한 IOPS 요구 사항의 50% 미만으로 떨어지면 다음과 같은 현상이 발생합니다.

◆ NetWorker 서버의 성능이 불안정해질 수 있습니다. ◆ NetWorker 서버에서 응답하지 않는 시간이 길어질 수 있습니다.◆ 백업 작업이 실패할 수 있습니다.

스토리지 성능과 관련한 NetWorker 서버 요구 사항은 다음 항목에 따라 결정됩니다.

◆ NetWorker 데이터 영역 모니터링

◆ 백업 작업

◆ 유지 보수 작업

◆ 보고 작업

◆ 수동 작업

NetWorker 데이터 영역 모니터링 요구 사항

스토리지는 NetWorker 서버에 대해 최소 30IOPS를 제공해야 합니다. NetWorker 서버 로드가 증가할수록 이 값도 높아집니다.

백업 작업 요구 사항

NetWorker 소프트웨어 워크로드에서 가장 큰 부분을 차지하는 항목은 백업 작업 시작 및 실행을 위한 요구 사항입니다.

◆ 로드에 따라 IOPS 요구 사항에 NetWorker 서버의 최대 동시 세션 수를 더한 다음 해당 결과를 3으로 나눕니다.

최대 NetWorker 서버 병렬 처리 수는 512이므로 가능한 최고 로드는 170IOPS 입니다.

◆ NetWorker 소프트웨어에서 인덱스 및 부트스트랩 백업을 동시에 수행해야 하는 경우에는 IOPS 요구 사항이 높아집니다. 이 경우에는 다음 값을 더합니다.

• 소형 서버의 경우 50IOPS • 중형 서버의 경우 150IOPS • 대형 서버의 경우 400IOPS

소형, 중형 및 대형 NetWorker 서버에 대한 지침은 23페이지의 표 4에 나와 있습

니다.

부트스트랩 백업이 일반 백업 작업과 동시에 실행되는 경우에만 추가 IOPS를 더합 니다. NetWorker 서버가 유휴 상태일 때 부트스트랩 백업이 실행되도록 구성된 경우에는 IOPS 요구 사항이 높아지지 않습니다.




◆ 그러나 NetWorker 소프트웨어가 많은 수의 작업을 동시에 시작하도록 구성된 경우

에는 IOPS 요구 사항이 높아집니다.

이 경우 로드 스파이크를 수용하려면 시작되는 각 병렬 세션에 대해 1IOPS를 추가합니다.

기본 클라이언트 병렬 처리 수(4)가 지정된 그룹당 클라이언트를 40개보다 많이 시작하지 않는 것이 좋습니다. 즉, 그룹 시작 중의 IOPS는 최대 160이어야 합니다.

많은 수의 클라이언트를 동시에 시작하면 입출력 시스템 결핍이 발생할 수 있습 니다.

◆ 각 볼륨 요청 시에는 몇 초 동안 짧은 입출력 폭주(약 200IOPS)가 발생합니다.

적은 수의 볼륨을 실행하는 환경에서는 폭주의 영향이 거의 없습니다. 그러나 마운 트 요청을 자주 수행하는 환경에서는 NetWorker 서버에 로드가 크게 추가됩니다. 이 경우 많은 작업량(시간당 마운트 요청 50건 초과)에 대비하여 100IOPS를 추가합니다. 과도한 로드를 방지하려면 적은 수의 대형 볼륨을 사용합니다.

◆ NDMP 백업 시에는 인덱스 사후 처리로 인해 로드가 추가됩니다.

파일이 1천만 개를 초과하는 대규모 NDMP 환경 백업의 경우 120IOPS를 더 추가합 니다.

내부 유지 보수 작업 요구 사항

유지 보수 작업을 완료하기 위한 요구 사항으로 인해 NetWorker 소프트웨어에 로드가 크게 추가될 수 있습니다.

◆ 일별 인덱스 및 미디어 데이터베이스 정합성 검사에서는 소규모 환경의 경우 40IOPS, 그리고 구성된 클라이언트 수가 1천 개를 초과하는 대규모 환경의 경우 최대 200IOPS를 추가합니다.

◆ 백업 및 보존 시간이 1년 이상으로 매우 긴 환경에서는 내부 데이터베이스가 매우 커져서 최대 100~200IOPS를 더 추가해야 합니다.

◆ 삭제 작업에서는 소규모 환경(일별 백업 작업 최대 1천 건)의 경우 30IOPS, 중간 규모 환경의 경우 100IOPS, 그리고 대규모 환경(일별 작업 5만 건의 높은 로드)의 경우 최대 200IOPS를 사용할 수 있습니다.

보고 작업 요구 사항

NMC 서버, DPA, 사용자 정의 보고 또는 모니터링 스크립트 등의 모니터링 툴로 인해 NetWorker 서버에 로드가 추가될 수 있습니다.

◆ 각 NMC 서버에 대해 100IOPS를 더 추가합니다.◆ DPA 보고를 사용하는 경우 250IOPS를 더 추가합니다.◆ 고객 보고 또는 모니터링 스크립트의 경우 설계에 따라 로드를 크게 증가시킬 수 있

습니다.

예를 들어 NetWorker 인덱스 및 미디어 데이터베이스에 대한 지속적인 보고를 수행하는 경우 500IOPS까지 추가될 수 있습니다.


수동 NetWorker 서버 작업 요구 사항

NetWorker 서버의 수동 작업으로 인해 로드가 더 추가될 수 있습니다.

◆ 백업 서버에서 객체를 열거해야 하는 각 복구 세션은 NetWorker 서버에 로드를 더 추가합니다.

예를 들어 백업 작업 1만 개를 완전히 열거하려면 NetWorker 서버에 최대 500IOPS가 필요할 수 있습니다.

◆ 스파이크 및 관련이 없는 운영 체제 워크로드의 경우에는 계산된 총 IOPS를 30% 늘려야 합니다.

◆ 대형 NetWorker 서버의 경우 단일 디스크 성능으로는 부족한 경우가 많습니다. 단일 디스크 성능에 대한 자세한 내용은 25페이지의 표 5에 나와 있습니다. IOPS를 높이

려면 병렬 액세스를 위해 여러 디스크를 조합합니다. 표준 디스크의 경우에는 RAID 0+1에서 최고의 성능을 얻을 수 있습니다. 그러나 최신 스토리지는 NetWorker 서버

의 무작위 워크로드를 위해 RAID 5 액세스용으로 최적화되는 경우가 많습니다. 하드

웨어 기반 Write-back 캐시는 NetWorker 서버 성능을 크게 향상시킬 수 있습니다

.NetWorker 서버 IOPS 요구 사항에 대한 지침은 23페이지의 표 4

표 4 NetWorker 서버 작업에 필요한 IOPS

작업 유형소규모 NetWorker 환경 1

중간 규모 NetWorker 환경 2

대규모 NetWorker 환경 3

에 나와 있습니다.

동시 백업 30 80 170

부트스트랩 백업 50 150 400

백업 그룹 시작 50 150 250

볼륨 관리 0 0 100

대규모 NDMP 백업 100 100 200

표준 일별 유지 보수 작업 40 75 100

대규모 내부 데이터베이스 유지 보수

0 100 200

삭제 작업 30 100 200

NMC 보고 50 75 100

DPA 보고 50 100 250

복구 30 200 500

1. 소규모 NetWorker 서버 환경은 클라이언트 수 또는 동시 백업 세션 수가 100개 미만인 환경입니다.

2. 중간 규모 NetWorker 서버 환경은 클라이언트 수가 100~400개이고 동시 백업 세션 수가 250개 이상인 환경입니다.

3. 대규모 NetWorker 서버 환경은 클라이언트 수가 401개 이상이거나 동시 백업 세션 수가 501개 이상인 환경입니다.



IOPS 고려 사항

이 섹션에서는 IOPS 값에 대한 고려 사항과 권장 사항을 제공합니다.

◆ NetWorker 소프트웨어는 데이터 영역당 클라이언트 수를 제한하지는 않지만, 대형 데이터 영역의 경우 관리하기가 복잡하며 NetWorker 서버에서 하드웨어 요구 사항

이 높아지므로 클라이언트는 1,000개까지만 포함하는 것이 좋습니다.

참고: NetWorker 서버의 입출력 로드가 높아질수록 스토리지 계층 서비스 시간도 길어집니다. 서비스 시간이 필요한 값을 초과하면 NetWorker 서버 성능 및 신뢰성에 직접적인 영향을 주게 됩니다. 최대 서비스 시간 요구 사항에 대한 자세한 내용은 59페

이지의 "NetWorker 서버 및 스토리지 노드 디스크 쓰기 지연"에 나와 있습니다.

◆ NetWorker 서버는 데이터 이동 자체를 수행하며, 백업 디바이스가 NetWorker 스토리

지 노드가 아닌 서버에 상주하는 경우 백업 성능이 직접적인 영향을 받습니다.

◆ 구성에 따라서는 같은 물리적 스토리지 서브시스템의 성능이 서로 다를 수 있습

니다. 예를 들어 단일 NetWorker 마운트 지점(/nsr)을 여러 마운트 지점으로 분할하

면 운영 체제의 기본 파일 시스템 핸들러가 병렬 처리를 수행할 수 있으므로 성능이 크게 향상될 수 있습니다. 자세한 내용은 59페이지의 "스토리지 최적화"에서 찾아

볼 수 있습니다.

◆ NetWorker 소프트웨어는 커밋된 입출력 쓰기를 사용하므로 각 쓰기 작업을 플러시

할 때 쓰기 캐시는 운영 체제에 거의 또는 전혀 영향을 미치지 않습니다. 그러나 하드

웨어 기반 Write-back 캐시는 NetWorker 서버 성능을 크게 향상시킬 수 있습니다.

예 1 및 예 2는 위에 나와 있는 요구 사항을 기준으로 합니다.

예 1 소규모 및 중간 규모 NetWorker 데이터 영역:

◆ 최적화: 병렬로 실행되는 다음과 같은 특성의 클라이언트 200개

• 100개의 작업(일별 백업 작업 최대 1천 건)• 백업이 시간에 따라 분산됨

• 외부 보고 없음 • 중복된 유지 보수 작업 없음

◆ 필요한 최소 IOPS: 200, 권장 IOPS: 400

◆ 비최적화: 워크로드는 동일하지만 특성이 다음과 같음

• 대부분의 백업 작업이 동시에 시작됨 • 운영 백업이 부트스트랩 및 유지 보수 작업과 중복됨

• 추가 보고가 있음

• 필요한 최소 IOPS: 800, 권장 IOPS 1,000

예 2 대규모 NetWorker 데이터 영역:

◆ 최적화: 병렬로 실행되는 다음과 같은 특성의 클라이언트 1,000개

• 500개의 작업(일별 백업 작업 최대 5만 건) • 백업이 시간에 따라 분산됨 • 디스크 또는 대형 테이프 볼륨으로의 백업을 사용하는 백업

• 외부 보고 없음

• 중복된 유지 보수 작업 없음

◆ 필요한 최소 IOPS: 800, 권장 IOPS: 1,000



◆ 비최적화: 워크로드는 동일하지만 특성이 다음과 같음

• 대부분의 백업 작업이 동시에 시작됨

• 많은 수의 소형 볼륨이 사용됨

• 운영 백업이 부트스트랩 및 유지 보수 작업과 중복됨

• 추가 보고가 있음

◆ 필요한 최소 IOPS: 2,000, 권장 IOPS: 2,500

이 예제에서는 NetWorker 구성의 차이로 인해 NetWorker 서버에 로드가 250%까지 더 추가될 수 있음을 확인할 수 있습니다. 또한 사이징에 대한 영향으로 인해 효율적으로 최적화된 대규모 환경의 성능이 최적화되지 않은 중간 규모 환경보다 우수하다는 점도 확인 가능합니다.

디스크 드라이브 기술에 대한 IOPS 값25페이지의 표 5에는 각 디스크 드라이브 유형 및 해당 IOPS 값이 나와 있습니다.

파일 기록 처리

파일 기록은 백업 중이 아니라 백업 작업이 끝날 때 NDMP에 의해 처리됩니다. 따라서 인지 유휴 시간이 길어집니다.

실제 파일 기록 처리 시간은 데이터 세트의 파일 수에 관계없이 선형입니다. 그러나 처리 시간은 다음과 같은 기타 스토리지 시스템 요소에 따라 달라집니다.

◆ RAID 유형

◆ 구성 중인 디스크 수

◆ 캐시 크기

◆ /nsr/index 및 /nsr/tmp를 호스팅할 파일 시스템의 유형

참고: 예상 처리 시간은 파일 1천만 개당 약 20분입니다.

파일 기록을 처리할 때는 백업 서버에서 많은 양의 입출력 로드가 생성되며 IOPS 요구 사항이 처리 중 초당 입출력 작업 100~120개만큼 증가합니다. 최소 IOPS 요구 사항이 충족

되지 않으면 파일 기록 처리가 상당히 느려질 수 있습니다.

표 5 디스크 드라이브 IOPS 값

디스크 드라이브 유형 디바이스당 값

EFD(엔터프라이즈용 플래시 드라이브)

초당 2,500개 입출력(무작위 소형 블록 입출력) 또는 초당 100MB 순차 대형 블록

Fibre Channel 드라이브 (FC 드라이브(15k RPM))

초당 180개 입출력(무작위 소형 블록 입출력) 또는 초당 12MB 순차 대형 블록

FC 드라이브(10K RPM) 초당 140개 입출력(무작위 소형 블록 입출력) 또는 초당 10MB 순차 대형 블록

SATA2 또는 LCFC (7200 RPM)

초당 80개 입출력(무작위 소형 블록 입출력) 또는 초당 8MB 순차 대형 블록

SATA 드라이브(7200 RPM) 초당 60개 입출력(무작위 소형 블록 입출력) 또는 초당 7MB 순차 대형 블록

PATA 드라이브(5400 RPM) 초당 40개 입출력(무작위 소형 블록 입출력) 또는 초당 7MB 순차 대형 블록



네트워크

네트워크 구성 성능에 영향을 주는 구성 요소는 다음과 같습니다.

◆ IP 네트워크:

네트워크 통신의 소스 및 대상을 확인하기 위해 인터넷 프로토콜을 지원하는 디바이스로 구성된 컴퓨터 네트워크입니다.

◆ 스토리지 네트워크:

테이프, 디스크, 파일 시스템 등의 물리적 스토리지가 상주하는 시스템입니다.

◆ 네트워크 속도:

데이터가 네트워크를 통해 이동하는 속도입니다.

◆ 네트워크 대역폭:

컴퓨터 네트워크의 최대 처리량입니다.

◆ 네트워크 경로:

네트워크에서 데이터 전송에 사용되는 통신 경로입니다.

◆ 네트워크 동시 로드

최종적으로 대역폭을 최대화하기 위해 데이터가 네트워크에서 배치되는 지점입 니다.

◆ 네트워크 지연:

네트워크에서 소스 디바이스와 타겟 디바이스 간의 데이터 이동에 대한 시간 지연 측정값입니다.

타겟 디바이스

타겟 디바이스 구성에서 성능에 영향을 주는 구성 요소는 다음과 같습니다.

◆ 스토리지 유형:

• 원시 디스크와 디스크 어플라이언스 비교:

– 원시 디스크: 파일 시스템 레벨 아래의 원시 바이너리 레벨에서 하드 디스크

를 액세스합니다.

– 디스크 어플라이언스: 서버, 스토리지 노드 및 소프트웨어로 이루어진 시스템

입니다.

• 물리적 테이프와 VTL(Virtual Tape Library) 비교:

– VTL은 NetWorker 소프트웨어에서 스토리지 미디어로 사용하기 위한 테이프 라이브러리 또는 테이프 드라이브 역할을 하는 스토리지 구성 요소(보통 하드 디스크 스토리지)를 제공합니다.

– 물리적 테이프는 이동식 스토리지 미디어 유형으로, 보통 마그네틱 테이프를 매체로 포함하는 볼륨이나 카트리지를 나타냅니다.

◆ 접속성:

• 로컬 SAN 연결:

디스크 스토리지 및 테이프 라이브러리와 같은 공유 스토리지 디바이스를 서버

에 연결하도록 설계된 컴퓨터 네트워크(LAN 또는 WAN과는 별도)입니다.



• IP 연결:

스토리지 디바이스에는 고유한 자체 IP 주소가 있습니다.

구성 요소 70% 규칙

실제 백업 환경에서는 이론적인 환경을 토대로 한 제조업체 처리량 및 성능 사양에 도달

하기가 어렵거나 불가능합니다. 따라서 모든 구성 요소에 대한 정격 용량의 70%를 초과

하지 않는 것이 좋습니다. 구성 요소는 다음과 같습니다.

◆ CPU

◆ 디스크

◆ 네트워크

◆ 내부 버스

◆ 메모리◆ Fibre Channel

활용도 임계값 70%를 초과하면 성능이 크게 저하되고 응답 시간이 매우 길어집니다.

단, 물리적 테이프 드라이브 및 SSD는 활용도가 임계값의 100%에 최대한 근접해야 합니다. 테이프 드라이브와 SSD 모두 사용량이 많아도 성능이 저하되지 않습니다.

NetWorker 환경의 구성 요소이 섹션에서는 NetWorker 데이터 영역의 구성 요소에 대해 설명합니다. 28페이지의 그림 3은 NetWorker 환경의 기본 구성 요소를 보여 줍니다. NetWorker 환경을 구성하는 기술 및 구성 요소는 다음과 같습니다.

◆ 28페이지의 "데이터 영역"

◆ 28페이지의 "NetWorker Management Console"

◆ 30페이지의 "NetWorker Server"

◆ 32페이지의 "NetWorker storage node"

◆ 32페이지의 "NetWorker 클라이언트"

◆ 33페이지의 "NetWorker 데이터베이스"

◆ 33페이지의 "선택적 NetWorker 애플리케이션 모듈"

◆ 33페이지의 "가상 환경"

NetWorker 환경의 구성 요소 27


◆ 33페이지의 "NetWorker 중복 제거 노드"

그림 3 NetWorker 데이터 영역 구성 요소

데이터 영역

데이터 영역은 한 대의 NetWorker 서버와 그에 연결된 클라이언트 컴퓨터입니다. 백업 요구 사항이 증가함에 따라 데이터 영역을 더 추가할 수 있습니다.

참고: NetWorker 데이터 영역당 클라이언트는 1,500개, 클라이언트 인스턴스는 3,000개 이하로 포함하는 것이 좋습니다. 이 값은 평균 NetWorker 서버를 반영하며 고정적 제한

은 아닙니다.

NetWorker Management Console

NMC(NetWorker Management Console)는 백업 서버를 관리하는 데 사용되며 백업 보고 기능을 제공합니다.

NMC는 백업 서버에서 실행되는 경우가 많으며 백업 서버에 많은 로드를 추가합니다. 대규모 환경에서는 NMC를 별도의 컴퓨터에 설치하는 것이 좋습니다. 단일 NMC 서버를 사용하여 여러 백업 서버를 관리할 수 있습니다.

NetWorker 서버

콘솔 사용자 인터페이스

디바이스콘솔 서버 Storage Node

NetWorker 클라이언트

데이터 영역



NMC 성능을 결정하는 구성 요소

NMC의 성능을 결정하는 구성 요소는 다음과 같습니다.

◆ 백업 서버에 대한 TCP 네트워크 연결: NMC와 NW 서버 간의 모든 통신은 TCP를 통해 이루어지므로 지연 시간이 짧은 고속 네트워크 연결이 반드시 필요합니다.

◆ 메모리: 대규모 환경의 데이터베이스 작업에서는 메모리를 많이 사용하므로 NMC 서버의 메모리가 충분해야 합니다.

◆ CPU: 여러 사용자가 NMC 서버를 사용하는 경우에는 각 사용자에게 충분한 CPU 시간

이 제공될 정도로 CPU 성능이 충분한지 확인합니다.

NMC 서버의 최소 시스템 요구 사항

이 섹션에서는 NMC 서버의 일부 특정 최소 요구 사항을 소개합니다.

◆ 메모리:

최소 1GHz(512MB RAM)가 필요합니다. 보고서를 실행하려면 512MB RAM을 더 추가합니다.

◆ 사용 가능한 디스크 공간:

듀얼 코어 2GHz 및 2GB RAM(사용자 수가 많은 대형 콘솔 데이터베이스용으로 디스크 공간 버퍼 포함)이 필요합니다.

◆ JRE(Web Start 포함):

55MB. NetWorker를 통해 모니터링되는 서버 수가 증가함에 따라 프로세서 용량을 늘립니다.

• 서버가 50대인 경우: 이중 1GHz, 2GB RAM 이상



콘솔 데이터베이스

이 섹션에서는 콘솔 데이터베이스의 크기와 공간 요구 사항을 추정하는 방법에 대해 설명합니다.

◆ 29페이지의 "NetWorker Management Console 데이터베이스의 크기 추정 수식"

◆ 30페이지의 "콘솔 데이터베이스 정보에 필요한 공간을 추정하는 수식"

NetWorker Management Console 데이터베이스의 크기 추정 수식

콘솔 서버는 엔터프라이즈의 NetWorker 서버에서 데이터를 수집하고 로컬 콘솔 데이터

베이스에 저장합니다. 기본적으로 데이터베이스는 최대한의 사용 가능한 공간을 제공

할 수 있는 로컬 파일 시스템에 설치됩니다. 콘솔은 이 정보를 통합하고 처리하여, 동향 분석, 용량 계획, 문제 감지 등을 용이하게 하는 보고서를 생성합니다. 보고서에 대한 자세한 내용은 NetWorker 관리 가이드를 참조하십시오.

수집된 데이터를 저장하려면 콘솔 데이터베이스에 충분한 디스크 공간을 할당합니다. 필요한 디스크 공간은 다음과 같은 여러 요소의 영향을 받습니다.

◆ 보고서가 모니터링되는 NetWorker 서버의 수◆ 해당 서버 각각에서 실행되는 savegroup의 수◆ savegroup이 실행되는 빈도

◆ 보고 데이터가 저장되는 시간(데이터 보존 정책)



참고: 필요한 디스크 공간은 저장된 기록 데이터 양과 직접 관련되므로 요구 사항은 평균 0.5GB에서 몇 GB까지 크게 차이가 날 수 있습니다. 하드웨어 요구 사항을 계획할 때 이러한 사항을 고려하십시오.

콘솔 데이터베이스 정보에 필요한 공간을 추정하는 수식

이러한 수식을 사용하여 서로 다른 유형의 데이터에 필요한 공간 및 총 필요 공간을 추정

합니다.

세이브 세트 미디어 데이터베이스

세이브 세트 미디어 데이터베이스에 필요한 공간을 추정하려면 주간 세이브 세트 양과 다음 수를 곱합니다.

◆ 콘솔에서 모니터링하는 NetWorker 서버 수◆ 세이브 세트 출력 정책의 주 수

이 결과는 세이브 세트가 성공적으로 실행되는 데 걸린 시간을 나타냅니다. 또한 백업된 파일 수 및 작업 중에 저장된 데이터 양을 나타냅니다.

세이브 세트 출력

세이브 세트 미디어 데이터베이스에 필요한 공간을 추정하려면 주간 출력 메시지 양과 다음 수를 곱합니다.

◆ 콘솔에서 모니터링하는 NetWorker 서버 수◆ 세이브 세트 출력 보존 정책

이 결과는 시도된 그룹 및 세이브 세트 수 및 성공 또는 실패 여부를 나타냅니다.

Savegroup 완료 데이터

세이브 세트 미디어 데이터베이스에 필요한 공간을 추정하려면 주간 savegroup 양과 다음 수를 곱합니다.

◆ 콘솔에서 모니터링하는 NetWorker 서버 수◆ 완료 데이터 보존 정책의 주 수

이 결과를 사용하여 백업 문제를 해결할 수 있습니다.

NetWorker Server

NetWorker 서버는 한 데이터 영역에 있는 NetWorker 클라이언트 컴퓨터에 대한 데이터 백업 및 복구 서비스를 제공합니다. NetWorker 서버는 스토리지 노드로도 사용될 수 있으며 여러 원격 스토리지 노드를 제어할 수 있습니다.

NetWorker 서버의 기본 프로세스에는 인덱스 및 미디어 관리 작업이 포함됩니다.

◆ 클라이언트 파일 인덱스는 세이브 세트에 속한 파일을 추적합니다. 클라이언트마다 클라이언트 파일 인덱스가 하나씩 있습니다.

◆ 미디어 데이터베이스는 다음을 추적합니다.

• 볼륨 이름

• 물리적 미디어에 있는 각 세이브 세트 조각의 위치(파일 번호/파일 레코드)

• 해당 볼륨에 있는 세이브 세트의 백업 날짜



• 각 세이브 세트에 있는 파일 시스템

◆ 미디어 데이터베이스는 클라이언트 파일 인덱스와 달리 서버당 하나씩만 있습니다.

◆ 클라이언트 파일 인덱스와 미디어 데이터베이스는 시간이 지나면 지나치게 커져서 백업 성능을 저하시킬 수 있습니다.

◆ NetWorker 서버는 모든 백업 작업을 예약 및 대기시키고 실시간 백업을 추적하며 관련 작업과 모든 NMC 통신을 복원합니다. 이 정보는 jobsdb에 제한된 시간 동안 저장

되는데, 실시간 작업의 경우에는 이 데이터베이스가 백업 서버 성능에 가장 큰 영향

을 줍니다.

참고: 복원 작업에는 이 데이터베이스에 저장되는 데이터가 필요하지 않습니다.

백업 서버 성능을 결정하는 구성 요소

NetWorker 서버 백업 성능을 결정하는 몇 가지 구성 요소는 다음과 같습니다.

◆ NetWorker 서버에 대해 64비트 시스템을 사용합니다.

◆ NetWorker 서버에 대해 최신 하드웨어를 사용합니다. 예를 들어 제작된 지 10년이 넘은 하드웨어에서는 최신 버전의 NetWorker 서버 소프트웨어가 정상적으로 작동하

지 않습니다.

◆ 동시 백업/복제/복구 스트림 수가 많은 경우와 같이 로드가 많을 때는 NetWorker 서버에서 다음과 같이 시스템 리소스를 많이 사용하는 작업을 최소화합니다.

• nsrim• nsrck

◆ NetWorker 서버를 호스팅하는 데 사용되는 디스크(/nsr):

일반적인 NetWorker 서버 워크로드는 여러 개의 작은 입출력 작업으로 구성됩니다. 따라서 지연 시간이 긴 디스크의 경우 피크 대역폭에서도 성능이 떨어집니다. 대규모 환경에서는 높은 지연 속도가 백업 서버 병목 현상의 가장 일반적인 원인입니다.

◆ 추가 소프트웨어 계층을 사용하면 스토리지 지연 시간이 더 길어지므로 사용하지 않습니다. 예를 들어 바이러스 백신 소프트웨어를 구성할 때는 해당 제외 목록에 NetWorker 데이터베이스(/nsr)를 포함해야 합니다.

◆ 복제 기술은 스토리지 지연 시간을 크게 증가시키므로 사용을 면밀하게 계획해야 합니다.

◆ 대규모 서버의 경우 CPU 성능이 모든 내부 데이터베이스 작업을 완료하기에 충분한

지 확인합니다.

◆ 적은 수의 CPU를 사용합니다. 적은 수의 고성능 CPU를 사용하는 시스템의 성능이 저성능 CPU 여러 개를 사용하는 시스템보다 뛰어납니다.

◆ 많은 수의 고성능 테이프 드라이브 또는 AFTD 디바이스를 백업 서버에 직접 연결하

지 마십시오.

◆ 서버의 메모리가 모든 내부 데이터베이스 작업을 완료하기에 충분한지 확인합니다.

◆ 스토리지 노드로 사용해야 하는 클라이언트 경우 가능하면 데이터를 백업 서버에 직접 저장하여 백업을 전용 스토리지 노드로 이동합니다.



참고: 대규모 환경에서는 스토리지 노드 처리로 인해 많은 시스템 로드가 생성될 수 있습니다. 엔터프라이즈 환경에서 백업 서버는 해당 내부 데이터베이스(인덱스 및 부트

스트랩)만 백업해야 합니다.

NetWorker storage node

NetWorker 스토리지 노드는 NetWorker 서버로부터 백업 또는 복구 작업과 관련된 데이

터 이동 작업 부담을 덜어 성능을 향상시키는 데 사용됩니다. NetWorker 스토리지 노드

에는 로컬 클라이언트 또는 네트워크 클라이언트에서 타겟 디바이스로의 데이터 전송

을 관리하기 위한 높은 입출력 대역폭이 필요합니다.

스토리지 노드 성능을 결정하는 구성 요소

스토리지 노드 성능을 결정하는 몇 가지 구성 요소는 다음과 같습니다.

◆ 백업을 저장하는 데 사용되는 타겟 디바이스의 성능

◆ 시스템 접속. 예를 들어 TCP 네트워크 백업에 사용되는 스토리지 노드가 데이터를 저장할 수 있는 속도는 클라이언트로부터 데이터를 수신할 수 있는 속도에 해당합

니다.

◆ 입출력 대역폭: 각 스토리지 노드는 사용 가능한 시스템 대역폭을 사용하므로, 입출

력 대역폭이 충분한지 확인합니다. 모든 디바이스의 백업 성능은 시스템 자체의 입출력 대역폭에 의해 제한됩니다.

◆ CPU: CPU가 많은 양의 데이터를 보내고 받기에 충분한지 확인합니다.

◆ ATA 또는 SATA 드라이브를 사용하여 스테이징 및 백업 작업이 VTL 또는 AFTD 솔루션

과 중복되지 않도록 합니다. 스토리지 성능과 관계없이 ATA 기술은 병렬 읽기 및 쓰기 스트림의 성능을 크게 저하시킵니다.

NetWorker 클라이언트

NetWorker 클라이언트 컴퓨터는 데이터를 백업해야 하는 컴퓨터입니다. NetWorker 콘솔 서버, NetWorker 서버 및 NetWorker 스토리지 노드 역시 NetWorker 클라이언트입니다. NetWorker 클라이언트는 미션 크리티컬 데이터를 포함하며 리소스를 많이 사용합니다. NetWorker 클라이언트의 애플리케이션이 CPU, 네트워크 및 입출력 리소스를 주로 사용

합니다. 추가 처리가 필요 없는 작업은 클라이언트에서 수행되는 읽기 작업뿐입니다.

클라이언트 속도는 한 시점에서 특정 클라이언트 백업의 모든 활성 인스턴스에 의해 결정됩니다.

NetWorker 클라이언트 성능을 결정하는 구성 요소

NetWorker 클라이언트 성능을 결정하는 몇 가지 구성 요소는 다음과 같습니다.

◆ 클라이언트 백업은 리소스를 많이 사용하는 작업으로, 기본 애플리케이션의 성능에 영향을 줍니다. 애플리케이션에 대해 시스템을 사이징할 때는 백업 및 관련 대역폭 요구 사항을 고려하십시오. 또한 클라이언트 애플리케이션은 CPU 및 입출력 리소스

를 많이 사용하므로 백업 속도를 떨어뜨립니다.

NetWorker 클라이언트의 리소스가 충분하지 않으면 백업 및 애플리케이션 성능이 모두 저하됩니다.



◆ 파일 수가 매우 많은 NetWorker 클라이언트. 대부분의 백업 애플리케이션은 파일 기반 솔루션이므로 파일 시스템에서 생성하는 모든 파일을 처리하는 데 시간이 매우 많이 걸리는데, 이로 인해 NetWorker 클라이언트 백업 성능이 저하됩니다. 예를 들어,

• 20KB 파일 5백만 개를 전체 백업하는 경우 200KB 파일 50만 개를 백업하는 것보

다 시간이 훨씬 오래 걸립니다. 두 경우 모두 100GB의 세이브 세트가 생성되는 것은 동일합니다.

• 변경되는 전체 데이터의 양이 동일한 경우 100MB 파일 1천 개(수정된 파일 50개)의 증가분/차등 백업 시간이 1MB 파일 1백만 개(수정된 파일 50개)에 비해 훨씬 짧습니다.

◆ 암호화 및 압축은 NetWorker 클라이언트에서 리소스를 많이 사용하는 작업으로, 백업 성능에 큰 영향을 줄 수 있습니다.

◆ 백업 데이터는 타겟 스토리지로 전송하여 백업 서버에서 처리해야 합니다.

• 클라이언트/스토리지 노드 성능:

– 로컬 스토리지 노드: 공유 메모리를 사용하며 오버헤드가 추가로 필요하지 않습니다.

– 원격 스토리지 노드: 수신 성능이 네트워크 구성 요소에 의해 제한됩니다.

• 클라이언트/백업 서버 로드:

백업 서버의 크기가 너무 작은 경우가 아니면 대개 클라이언트 백업 성능을 저하

시키지 않습니다.

NetWorker 데이터베이스

NetWorker 데이터베이스의 크기를 결정하는 요소는 39페이지의 "NetWorker 데이터베이

스 병목 현상"에 나와 있습니다.

선택적 NetWorker 애플리케이션 모듈

NetWorker 애플리케이션 모듈은 특정 온라인 백업 작업에 사용됩니다. 애플리케이션 백업 성능을 높이려면 애플리케이션 측 튜닝을 추가로 수행해야 할 수 있습니다. 자세한 내용은 해당하는 NetWorker 모듈 설명서에서 확인할 수 있습니다.

가상 환경

가상 머신에서 기존 백업 또는 VADP용으로 NetWorker 클라이언트를 생성할 수 있습

니다. 또한, NetWorker 소프트웨어는 가상 환경을 자동으로 발견하고 일정에 따라 또는 필요할 때마다 이러한 환경으로 전환하여 가상 환경을 그래픽 형태로 보여줍니다.

NetWorker 중복 제거 노드

NetWorker 중복 제거 노드는 중복 제거된 백업 데이터를 저장하는 EMC Avamar® 서버입

니다. 중복 제거 노드에 대한 초기 백업은 전체 백업이어야 합니다. 이후에 백업을 수행

하면 Avamar 인프라스트럭처는 소스에서 중복된 데이터 세그먼트를 식별하고 변경된 파일 전체를 백업하는 대신 고유한 세그먼트만 백업합니다. 이로 인해 NetWorker Management Console의 백업에 사용되는 네트워크 대역폭 및 스토리지 공간뿐 아니라 백업을 수행하는 데 필요한 시간을 줄일 수 있습니다.



복구 성능 요소복구 성능은 네트워크 트래픽, 병목 현상, 큰 파일 등의 영향을 받을 수 있습니다. 복구 성능에 대한 몇 가지 권장 사항은 다음과 같습니다.

◆ 파일 기반 복구 성능은 백업 서버의 성능(구체적으로는 클라이언트 파일 인덱스) 에 따라 달라집니다. 클라이언트 파일 인덱스에 대한 자세한 내용은 30페이지의 "NetWorker Server"에 나와 있습니다.

◆ 데이터를 효율적으로 복구하는 가장 빠른 방법은 세이브 세트 복구를 사용하여 여러 복구 명령을 동시에 실행하는 것입니다. 예를 들어 프로세스 수, 볼륨 및 세이브 세트 레이아웃이 주어진 경우 세이브 세트 복구 작업 3개를 사용하면 가능한 최대 수의 병렬 처리를 수행할 수 있습니다.

◆ 여러 동시 복구 작업이 동일한 테이프에서 실행되는 경우 모든 복구 요청이 준비될 때까지 테이프가 마운트 및 시작되지 않게 하십시오. 모든 요청이 준비되기 전에 테이프가 사용될 경우 테이프를 여러 번 읽기 때문에 복구 성능이 저하됩니다.

◆ 테이프로의 백업을 멀티플렉싱하면 복구 성능이 저하됩니다.

접속 및 병목 현상백업 환경은 시스템, 스토리지 네트워크 및 타겟 디바이스 구성 요소의 여러 디바이스로 구성되며 각 디바이스에서는 여러 공급업체의 다양한 모델을 사용할 수 있습니다.

접속 관련 성능에 영향을 주는 요소는 다음과 같습니다.

◆ 독립 실행형 디바이스로 사용할 때는 성능이 뛰어난 구성 요소라도, 체인의 다른 디바이스와 함께 사용할 때의 성능에 따라 구성의 최적 여부가 결정됩니다.

◆ 서로 통신할 수 없는 체인의 구성 요소는 아무런 소용이 없습니다.

◆ 백업은 데이터를 많이 사용하는 작업이며, 많은 양의 데이터를 생성할 수 있습니다. 비즈니스 요구 사항을 충족하려면 데이터를 최적의 속도로 전송해야 합니다.

◆ 체인에서 속도가 가장 느린 구성 요소가 병목 현상의 원인으로 간주됩니다.



35페이지의 그림 4에 나와 있는 네트워크는 구성 요소만큼 많은 데이터를 수집하고 보낼 수 없습니다. 따라서 네트워크는 병목 현상의 원인이 되며 전체 백업 프로세스의 속도

를 떨어뜨립니다. 허브, 스위치, NIC 등 체인의 모든 단일 네트워크 디바이스는 병목 현상

의 원인이 되어 전체 작업 속도를 저하시킬 수 있습니다.

그림 4 네트워크 디바이스 병목 현상

36페이지의 그림 5에 나와 있는 것처럼 네트워크가 100 Base T 네트워크에서 GigE 네트

워크로 업그레이드되었으며 병목 현상이 다른 디바이스로 이동되었습니다. 이제는 호스트가 사용 가능한 네트워크 대역폭을 활용하기에 충분히 빠르게 데이터를 생성하지 못합니다. CPU, 메모리 또는 기타 리소스가 부족한 경우 시스템 병목 현상이 발생할 수 있습니다.

접속 및 병목 현상 35


그림 5 업데이트된 네트워크

37페이지의 그림 6에 나와 있는 것처럼 NetWorker 클라이언트가 더 큰 시스템으로 업그

레이드되어 더 이상 병목 현상이 발생하지 않습니다. 이처럼 시스템 성능이 향상되고 네트워크 대역폭이 증가하면 타겟 디바이스에서 병목 현상이 발생합니다. 테이프 디바이

스는 다른 구성 요소만큼 성능이 뛰어나지 않은 경우가 많습니다. 테이프 디바이스 성능

을 제한하는 몇 가지 요소는 다음과 같습니다.

◆ 제한된 SCSI 대역폭

◆ 최대 테이프 드라이브 성능에 도달

Fibre Channel 기반 드라이브 등 성능이 보다 뛰어난 테이프 디바이스를 도입하여 타겟 디바이스 성능을 개선합니다. 이 경우 SAN 환경의 성능도 크게 개선될 수 있습니다.



그림 6 업데이트된 클라이언트

38페이지의 그림 7에 나와 있는 것처럼 SAN에 더 우수한 성능의 테이프 디바이스를 도입하면 해당 디바이스에서 더 이상 병목 현상이 발생하지 않습니다. 대신, 스토리지 디바이스에서 병목 현상이 발생합니다. 로컬 볼륨은 최적의 속도로 작동하지만 사용 가능

한 시스템, 네트워크 및 타겟 디바이스 리소스를 사용할 수 없습니다. 스토리지 성능을 개선하려면 데이터 볼륨을 고성능 외부 RAID 스토리지로 이동합니다.



그림 7 전용 SAN

로컬 볼륨은 최적의 속도로 작동하지만 사용 가능한 시스템, 네트워크 및 타겟 디바이스 리소스를 사용할 수 없습니다. 스토리지 성능을 개선하려면 데이터 볼륨을 고성능 외부 RAID 스토리지로 이동합니다.

39페이지의 그림 8에 나와 있는 것처럼 외부 RAID 스토리지를 통해 시스템 성능이 개선

되었습니다. RAID 스토리지의 성능은 체인의 다른 구성 요소와 거의 비슷하므로 성능 기대치가 충족됩니다. 병목 현상은 항상 발생하지만, 모든 디바이스의 성능이 체인의 나머

지 디바이스와 거의 같은 레벨이므로 병목 현상 발생 디바이스의 영향이 제한됩니다.



그림 8 RAID 스토리지

참고: 이 섹션에서는 성능을 개선하기 위해 모든 구성 요소를 업그레이드하도록 제안하

지는 않습니다. 대신 병목 현상의 개념을 설명하고, 체인의 다른 디바이스와 비슷한 속도로 작동하는 디바이스를 사용하는 것의 중요성을 부연 설명합니다.

NetWorker 데이터베이스 병목 현상

이 섹션에서는 NetWorker 데이터베이스 크기를 결정하는 요소를 소개합니다.

◆ NetWorker 리소스 데이터베이스 /nsr/res 또는 networker install dir/res: 구성된 리소

스의 수

◆ NetWorker 작업 데이터베이스(nsr/res/jobsdb): 백업, 복원, 복제 등의 작업 수에 보존하도록 설정된 기간(일)을 곱한 값. 이 값은 최대 규모의 환경에서 레코드 10만 개를 초과할 수 있으며, 성능 병목 현상을 일으키는 주요 항목 중 하나입니다. 전체 크기는 중요하지 않습니다.

◆ NetWorker 미디어 데이터베이스(nsr/mm): 보존된 세이브 세트 수 및 레이블이 지정

된 볼륨 수. 이 값은 최대 규모의 환경에서 수 GB의 데이터에 해당할 수 있습니다.



◆ NetWorker 클라이언트 파일 인덱스 데이터베이스(nsr/index): 인덱싱된 파일의 수 및 탐색 정책의 파일 수. 대개 NetWorker 데이터베이스 중 가장 큽니다. 스토리지 사이

징에는 다음 공식을 사용합니다.

인덱스 카탈로그 크기 = (n+(i*d))*c*160*1.5

여기서,

n = 백업할 파일의 수

d = 주기의 일 수(전체 백업 간의 시간)

i = 일별 증가분 데이터 변경(%)

c = 온라인 주기 수(탐색 정책)

통계 평균은 카탈로그의 항목당 160바이트입니다.

확장 및 오류를 고려하여 이 값에 1.5를 곱합니다.

참고: 인덱스 데이터베이스는 여러 위치로 분할할 수 있으며 위치는 클라이언트별

로 결정됩니다.

40페이지의 그림 9에는 NetWorker 미디어 데이터베이스가 상주하는 디스크 성능에서 병목 현상이 발생하는 경우의 전반적인 성능 저하 형태가 나와 있습니다. 오른쪽 차트에

는 순 데이터 쓰기 처리량(세이브 세트+인덱스+부트스트랩)이 나와 있고 왼쪽 차트에는 세이브 세트 쓰기 처리량이 나와 있습니다.

그림 9 NetWorker 서버 쓰기 처리량 저하


3장

설정 조정

NetWorker 소프트웨어에는 백업 환경을 조정하고 백업 및 복원 성능을 최적화하는 데 사용할 수 있는 다양한 최적화 기능이 있습니다.

이 장에 포함된 내용은 다음과 같습니다.

◆ NetWorker 병렬 처리 최적화................................................................................... 42◆ 파일 시스템 밀도.................................................................................................... 44◆ 디스크 최적화 ........................................................................................................ 45◆ 디바이스 성능 튜닝 방법........................................................................................ 45◆ 네트워크 디바이스................................................................................................. 47◆ 네트워크 최적화 .................................................................................................... 51◆ 스토리지 최적화 .................................................................................................... 59

설정 조정 41

설정 조정

NetWorker 병렬 처리 최적화 이 섹션에서는 서버, 그룹 및 클라이언트 병렬 처리에 대한 일반적인 Best Practice에 대해 설명합니다.

서버 병렬 처리 수

서버 병렬 처리 수 속성은 서버가 동시에 수용할 수 있는 세이브 스트림 수를 제어합

니다. 서버가 수용할 수 있는 세이브 스트림 수가 많을수록 디바이스와 클라이언트 디스

크가 더 빠르게 실행됩니다. 클라이언트 디스크는 성능 한계 또는 디스크 간의 연결 한계

에서 실행될 수 있습니다.

서버 병렬 처리는 백업 작업의 시작을 제어하는 데 사용되는 것이 아니라 백업 서버에서 허용하는 세션의 최종 한계로 사용됩니다. 서버 병렬 처리 수 값은 백업 서버 자체에 과부하를 발생시키지 않는 범위 내에서 최대한 크게 지정해야 합니다.

클라이언트 병렬 처리 수

클라이언트 병렬 처리 수 값을 지정하는 가장 적절한 방식은 다음과 같습니다.

◆ 일반 클라이언트의 경우 세이브 세트 수와 처리량 간에서 최적의 균형을 유지할 수 있도록 가능한 한 낮은 병렬 처리 수 설정을 사용해야 합니다.

◆ 백업 서버의 경우에는 인덱스 백업이 지연되지 않도록 최대한 높은 클라이언트 병렬 처리 수를 설정합니다. 이렇게 하면 그룹이 정상적으로 완료됩니다.

NetWorker 서버에 대해 클라이언트 병렬 처리 수가 너무 낮게 설정되어 있으면 백업이 지연되는 경우가 많습니다. NetWorker 클라이언트 성능을 최적화하는 가장 좋은 방법은 클라이언트 병렬 처리를 제거하고 병렬 처리 수를 1로 낮춘 다음 클라이언트 하드웨어 및 데이터 구성에 따라 병렬 처리 수를 늘리는 것입니다.

인덱스 백업이 그룹 완료에 영향을 주지 않도록 하려면 NetWorker 서버의 병렬 처리 수가 충분히 커야 합니다.

NetWorker 서버를 나타내는 클라이언트의 클라이언트 병렬 처리 수 값을 설정할 때는 다음 지침을 따르십시오.

◆ 병렬 처리 수를 1로 설정하지 않습니다.◆ 서버 수가 30대 이하인 소규모 환경에서는 병렬 처리 수를 8 이상으로 설정합니다.◆ 서버 수가 31~100대 사이인 중간 규모 환경에서는 병렬 처리 수를 12 이상으로 설정

합니다.◆ 서버 수가 100대를 초과하는 대규모 환경에서는 병렬 처리 수를 16 이상으로 설정합

니다.

이러한 권장 사항에서는 백업 서버가 전용 백업 서버라고 가정합니다. 성능을 최적화하

려면 백업 서버가 항상 전용 서버여야 합니다.


설정 조정

그룹 병렬 처리 수

그룹 병렬 처리 수 값을 설정하는 가장 적절한 방식은 다음과 같습니다.

◆ 그룹 병렬 처리 수가 적용된 클라이언트가 최대 50개 포함된 저장 그룹을 생성합

니다. 클라이언트 수가 50개를 초과하는 대형 저장 그룹의 경우 여러 운영 체제 프로

세스가 동시에 시작되어 운영 체제 리소스가 일시적으로 부족해질 수 있습니다.

◆ 이 경우 저장 그룹 시작 시간에 약간씩 시차를 두면 운영 체제에 대한 로드가 줄어듭

니다. 예를 들어 클라이언트를 200개 포함하는 저장 그룹 하나를 사용하는 것보다 클라이언트를 각각 50개씩 포함하는 저장 그룹 4개가 5분 간격으로 시작되도록 하는 것이 효율적입니다.

멀티플렉싱

타겟 세션 속성은 디바이스에 쓰는 동시 세이브 스트림의 타겟 수를 설정합니다. 이 값은 한계가 아니므로 디바이스에서 타겟 세션 속성이 지정하는 것보다 많은 세션을 수신할 수 있습니다. 타겟 세션에 대해 지정된 세션의 수가 많을수록 동일한 볼륨에서 더 많은 세이브 세트를 멀티플렉싱 또는 인터리빙할 수 있습니다.

디바이스 타겟 세션에 대한 자세한 내용은 49페이지의 "AFTD 디바이스 타겟 및 최대 세션"을 참조하십시오.

성능 테스트 및 평가에 따라 멀티플렉싱이 시스템에 적합한지 결정할 수 있습니다. 멀티

플렉싱 사용을 평가할 때는 다음 지침을 따릅니다.

◆ 각 디바이스의 최대 속도를 확인합니다. 64페이지의 "bigasm 지침"의 설명에 따라 bigasm 테스트를 사용합니다.

◆ 클라이언트에서 각 디스크의 백업 속도를 확인합니다. 64페이지의 "uasm 지침"의 설명에 따라 uasm 테스트를 사용합니다.

백업에 포함된 모든 디스크의 백업 속도 합계가 디바이스의 최대 속도보다 큰 경우 서버 병렬 처리 수를 늘리지 않습니다. 이 경우 더 많은 저장 그룹이 멀티플렉싱되면 백업 성능이 향상되지 않고 복구 성능이 저하될 수 있습니다.

NetWorker 병렬 처리 최적화 43

설정 조정

파일 시스템 밀도파일 시스템 밀도는 백업 처리량에 직접적인 영향을 줍니다. 특히 작은 파일 수가 많은 경우 파일 시스템 밀도에 따라 NetWorker 저장 작업의 시간이 매우 오래 걸릴 수 있습

니다. 고밀도 파일 시스템의 NetWorker 성능은 디스크 지연, 파일 시스템 유형 및 세이브 세트의 파일 수에 따라 달라집니다. 44페이지의 그림 10에는 파일 시스템 밀도가 백업 처리량에 주는 영향의 레벨이 나와 있습니다.

그림 10 파일 수와 처리량 간의 관계


설정 조정

디스크 최적화NetWorker 릴리즈 8.0에는 표준 파일 시스템 백업 중에 클라이언트로부터의 데이터 읽기 성능을 최적화하기 위한 새로운 기능이 도입되었습니다.

NetWorker 7.6 이하 버전에서는 클라이언트에서 파일을 읽을 때 고정 64K 블록을 사용합

니다. 반면 NetWorker 8.0에서는 이제 지능형 알고리즘을 사용하여 클라이언트 시스템

의 현재 읽기 성능을 기준으로 64KB~8MB 범위에서 최적의 블록 크기 값을 선택합니다. 이 블록 크기 선택은 실제 데이터 전송 중에 수행되고 백업 프로세스에 오버헤드를 추가

하지 않으며 디스크 읽기 성능을 크게 향상시킬 수 있습니다.

참고: 읽기 블록 크기는 백업에 사용되는 디바이스 블록 크기(변경되지 않은 상태로 유지됨)와 관계가 없습니다.

이 기능은 나머지 백업 프로세스에 영향을 미치지 않으며, 기능을 사용하기 위해 추가 구성을 수행할 필요도 없습니다.

NSR_READ_SIZE 환경 변수를 원하는 값으로 설정하여 동적 블록 크기를 재정의할 수 있습니다. 예를 들어 NSR_READ_SIZE=65536을 설정하는 경우 NetWorker 소프트웨어가 읽기 프로세스 중에 64KB 블록 크기를 사용하도록 강제 적용됩니다.

디바이스 성능 튜닝 방법이 섹션에서는 성능을 향상시킬 수 있는 특정 디바이스 관련 영역에 대해 설명합니다.

입력/출력 전송 속도

입력/출력(입출력) 전송 속도는 디바이스 성능에 영향을 줄 수 있습니다. 입출력 속도는 데이터를 디바이스에 쓰는 속도입니다. 디바이스 및 미디어 기술에 따라 디바이스 전송 속도는 초당 500KB에서 초당 200MB 사이일 수 있습니다. 디바이스의 기본 블록 크기와 버퍼 크기는 해당 전송 속도에 영향을 줍니다. 입출력 제한으로 인해 NetWorker 서버의 성능이 저하되는 경우 전송 속도가 높아지도록 디바이스를 업그레이드해 봅니다.

내장된 압축

디바이스에 대한 실제 처리량을 늘리려면 디바이스 압축을 설정합니다. 일부 디바이스

에는 내장된 하드웨어 압축 기능이 있습니다. 백업 데이터를 얼마나 압축할 수 있는지에 따라 실제 데이터 처리량이 1.5:1 - 3:1의 비율로 향상될 수 있습니다.

드라이브 스트리밍

대부분의 디바이스에서 최대한의 성능을 확보하려면 지속 가능한 최대 처리량으로 드라이브를 스트리밍합니다. 드라이브 스트리밍을 하지 않을 경우, 드라이브는 쓰기를 다시 시작하기 전에 버퍼가 다시 채워지거나 미디어가 재배치될 때까지 기다리면서 중지

된 상태로 있어야 합니다. 이 경우 디바이스에 따라 드라이브의 주기 내에서 지연이 발생

할 수 있습니다.

디스크 최적화 45

설정 조정

디바이스 로드 밸런싱

디바이스당 타겟 및 최대 세션을 조정하여 사용 가능한 디바이스에서 동시 세션에 대한 데이터 로드를 균등하게 밸런싱합니다. 이 매개 변수는 NetWorker 서버에서 저장 세션을 다른 디바이스에 할당하려고 시도하기 전에 설정해야 할 최소 저장 세션 수를 지정합니

다. 디바이스 타겟 및 최대 세션에 대한 자세한 내용은 49페이지의 "AFTD 디바이스 타겟 및 최대 세션"을 참조하십시오.

디스크 드라이브 조각화

Windows 클라이언트에서 파일 시스템이 조각화되면 조각화 정도에 따라 성능이 크게 저하될 수 있습니다. 최적의 파일 시스템 백업 성능을 유지하려면 다음을 따르십시오.

1. NetWorker를 사용하지 않는 복제 또는 ftp 작업을 수행하여 클라이언트의 파일 시스

템 성능을 확인해 디스크 조각화가 문제가 될 수 있는지를 파악합니다.

2. 클라이언트에서 디스크 조각 모음 툴을 실행하여 디스크가 보다 효율적으로 작동할 수 있도록 데이터를 통합합니다.

a. 디스크 조각 모음을 클릭하여 엽니다.

b. 현재 상태에서 조각 모음을 수행할 디스크를 선택합니다.

c. 디스크 분석을 클릭하여 조각화가 문제의 원인인지 확인합니다. 관리자 암호를 묻거나 확인을 요청하는 메시지가 나타나면 암호를 입력하거나 확인합니다.

d. Windows에서 디스크 분석이 완료되면 마지막 실행 열에서 디스크의 조각화 비율을 확인합니다. 비율 값이 10%보다 크면 디스크 조각 모음을 수행합니다.

e. 디스크 조각 모음을 클릭합니다. 관리자 암호를 묻거나 확인을 요청하는 메시지

가 나타나면 암호를 입력하거나 확인합니다.

하드 디스크의 크기와 조각화 정도에 따라 조각 모음이 완료되려면 몇 분에서 몇 시간까지 걸릴 수 있습니다. 조각 모음 프로세스 중에도 컴퓨터를 사용할 수 있습

니다.


설정 조정

네트워크 디바이스원격 클라이언트에서 데이터를 백업할 경우 라우터, 네트워크 케이블 및 네트워크 인터

페이스 카드는 백업 및 복구 작업에 영향을 줍니다. 이 섹션에서는 네트워크 하드웨어의 성능 변수를 소개하고 네트워크에서 수행할 수 있는 몇 가지 기본적인 튜닝 작업을 제안

합니다. 다음 항목은 특정 네트워크 문제를 해결합니다.

◆ 네트워크 입출력 대역폭:

네트워크 프로토콜 오버헤드로 인해 네트워크에서 최대 데이터 전송 속도가 제조업체의 사양에 도달하는 경우는 거의 없습니다.

참고: 네트워크 대역폭 문제를 해결하려는 경우 전반적인 시스템 사이징에 관한 다음 사항을 고려해야 합니다.

각각의 연결된 테이프 드라이브(물리적 VTL 또는 AFTD)는 사용 가능한 입출력 대역폭을 활용하며, 데이터도 처리해야 하기 때문에 CPU도 사용합니다.

◆ 네트워크 경로:

라우터, 브리지 및 허브와 같은 네트워킹 구성 요소는 일부 오버헤드 대역폭을 사용하기 때문에 네트워크 처리 성능을 떨어뜨립니다.

◆ 네트워크 로드:

• 각 IP 주소는 CPU 리소스를 많이 사용하므로 여러 개의 고속 NIC를 NetWorker 서버에 직접 연결하지 마십시오. 예를 들어 1GB NIC가 4개인 중형 시스템의 경우 백업 중에 TCP 데이터를 처리하는 데 해당 리소스를 50% 넘게 사용합니다.

• 기타 네트워크 트래픽 역시 NetWorker 서버에서 사용할 수 있는 대역폭을 제한하

고 백업 성능을 저하시킵니다. 네트워크 로드가 포화 임계값에 도달한 경우 데이

터 패킷 충돌로 인해 성능이 더욱 저하됩니다.

Fiber Channel 지연

링크 지연의 영향을 줄이려면 NetWorker 볼륨의 블록 크기를 늘리십시오.

볼륨 블록 크기를 늘리면 라운드 트립 승인을 자주 받을 필요 없이 디바이스로 데이터 스트림을 전달할 수 있습니다.

지연 시간이 낮은 링크에서는 블록 크기를 늘려도 영향이 없습니다.

지연 시간이 높은 링크의 경우 블록 크기의 영향이 상당히 클 수 있으며 로컬 링크와 같은 레벨의 성능에 도달할 수는 없습니다.

참고: 느린 데이터 속도의 원인이 지연인 경우에는 대역폭을 높여도 성능이 바로 향상되

지 않습니다.

네트워크 디바이스 47

설정 조정

48페이지의 표 6에는 15KB 8Gb DWDM 링크를 통해 로컬로 연결된 물리적 LTP-4 테이프 드라이브에서 각 블록 크기의 예가 나와 있습니다.

48페이지의 그림 11에 나와 있는 것처럼 지연을 0.001ms에서 2.0ms로 설정하면 NetWorker 백업 처리량이 100%에서 0%로 떨어집니다.

그림 11 데이터 처리량에 대한 Fibre Channel 지연의 영향

DataDomain

다양한 기술을 사용하여 DataDomain 스토리지로의 백업을 구성할 수 있습니다.

◆ VTL로 백업:

NetWorker 디바이스는 테이프 디바이스로 구성되며 데이터 전송은 Fiber Channel을 통해 수행됩니다.

VTL 최적화에 대한 자세한 내용은 50페이지의 "가상 디바이스 드라이브 수와 물리적 디바이스 드라이브 수"에 나와 있습니다.

◆ CIFS 또는 NFS를 통해 AFTD로 백업:

• 전반적인 네트워크 처리량은 CIFS 및 NFS 성능(네트워크 구성에 따라 달라짐)의 영향을 받습니다.

51페이지의 "네트워크 최적화"에서는 CIFS 또는 NFS를 통해 AFTD로 백업하기 위한 Best Practice를 제공합니다.

• 기본 전송 기능의 효율성이 낮으면 백업 성능이 링크 속도의 70~80%로 제한됩

니다. 성능을 최적화하려면 NetWorker 릴리즈 7.5 서비스 팩 2 이상이 필요합

니다.

표 6 LTO-4 테이프 드라이브의 블록 크기에 대한 영향

블록 크기 로컬 백업 성능 원격 백업 성능

64KB 초당 173MB 초당 60MB






설정 조정

◆ NetWorker 8.0에 도입된 DFA(Direct File Access) 기능을 설정하는 Client Direct 속성 사용:

• Boost를 통한 DD(Data Domain)로의 Client Direct를 사용하면 CIFS/NFS를 통한 DFA-AFTD에 비해 성능이 크게 향상됩니다.

• Client Direct를 설정(DFA-DD/DFA-AFTD)한 상태의 백업 성능은 mmd를 사용한 기존 백업에 비해 20~60% 빨라집니다.

• 단일 디바이스로의 스트림 수가 늘어나면 DFA에서는 백업 스트림을 mmd에 비해 훨씬 효율적으로 처리합니다.

◆ 네이티브 디바이스 유형을 사용하여 DataDomain으로 백업:

• NetWorker 7.6 서비스 팩 1에서는 TCP/IP 링크를 통한 Data Domain 스토리지로의 네이티브 통신 전용으로 설계된 새로운 디바이스 유형이 제공됩니다.

• 네트워크를 적절하게 최적화하는 경우 이 프로토콜은 초당 10Gb의 속도에서도 링크 속도의 최대 95%를 사용할 수 있는 현존하는 가장 효율적인 네트워크 전송 기능입니다.

• NetWorker 7.6.1에서 NetWorker에 구성된 각 DataDomain 디바이스의 병렬 백업 스트림 수는 최대 10개로 제한됩니다. 병렬 처리 수를 더 크게 설정해야 하는 경우 NetWorker 서버 에디션에서 정의하는 한계까지 더 많은 디바이스를 구성합

니다.

• NetWorker 7.6.2 이상에서는 디바이스당 세션 수를 60개로 제한합니다.

DataDomain 스토리지로의 백업에 사용되는 방법과는 달리 집계 백업 성능은 특정 DataDomain 모델의 최대 유입 속도에 의해 제한됩니다.

◆ 각 디바이스의 총 스트림 수가 10개로 설정된 NetWorker DataDomain-OST 디바이스

에 필요한 최소 메모리는 약 160MB입니다. 즉, BOOST에 대한 각 OST 스트림은 약 16MB의 메모리를 사용합니다.

◆ DDBoost는 백업 작업 중에 비클라이언트 중복 제거 백업에 비해 훨씬 짧은 기간 동안 2~40%의 CPU 시간을 추가로 사용합니다. 그러나 DDBoost로 백업하는 경우의 전체 CPU 로드는 CIFS/NFS를 사용한 기존의 mmd 기반 백업에 비해 적습니다.

AFTD 디바이스 타겟 및 최대 세션

이 섹션에서는 지원되는 모든 운영 체제, 최적의 AFTD(Advanced File Type Device) 디바이

스 타겟 및 NetWorker 소프트웨어에 대한 최대 세션 설정에 대해 설명합니다. 여기에는 NetWorker 버전 7.6 이하 및 7.6 서비스 팩 1 이상 소프트웨어에 대한 설명도 포함됩니다.

NetWorker 7.6 이하 소프트웨어

현재 NetWorker 7.6 이하 버전에서 AFTD 타겟 세션 및 최대 세션 수에 대한 기본 설정

(각각 4, 512)은 AFTD 성능에 최적화된 값이 아닙니다.

NetWorker 7.6 이하 버전에 대해 AFTD 성능을 최적화하려면 기본값을 다음과 같이 변경

합니다.

◆ 디바이스 타겟 세션을 4에서 1로 설정합니다.◆ 디스크 스래싱(thrashing)을 방지하기 위해 디바이스 최대 세션을 512에서 32로 설

정합니다.

네트워크 디바이스 49

설정 조정

NetWorker 7.6 서비스 팩 1 이상

기본적으로 AFTD 타겟 세션 및 최대 디바이스 세션은 AFTD 성능을 위해 다음과 같이 최적의 값으로 설정되어 있습니다.

◆ 디바이스 타겟 세션: 1◆ 디바이스 최대 세션: 32(디스크 스래싱(thrashing)을 방지하기 위해)

필요한 경우 환경에 적합한 값을 반영하도록 디바이스 타겟 및 최대 세션 속성을 둘 다 수정할 수 있습니다.

NetWorker 8.0 이상 소프트웨어

NSR 스토리지 노드 속성의 동적 nsrmmd 속성은 nsrmmd 프로세스의 동적 프로비저닝을 위해 기본적으로 해제됩니다. 동적 nsrmmd 속성을 설정하면 동적 nsrmmd 프로비저닝

이 설정됩니다.

동적 nsrmmd 속성을 설정하는 경우 디바이스에 대한 세션 수가 타겟 세션 수를 초과

하면 같은 디바이스에 여러 nsrmmd 프로세스가 포함되는 동작 변화를 확인할 수 있습

니다. 이러한 현상은 최대 nsrmmd 수 또는 최대 세션 수 값 중 더 작은 값에 도달할 때까

지 계속됩니다.

B2D(Backup-to-Disk)를 설정하려면 구성 탭을 선택하고 다음 속성을 필요한 대로 설정합

니다.

◆ 타겟 세션은 사용 가능한 다른 디바이스를 사용할 때까지 디바이스에서 처리하는 세션의 수입니다. 최상의 성능을 유지하려면 이 값을 낮게 설정해야 합니다. 기본값은 4(FTD/AFTD) 및 6(DD Boost 디바이스)이며 60보다 큰 값으로는 설정할 수 없습니다.

◆ 최대 세션의 기본값은 32(FTD/AFTD) 및 60(DD Boost 디바이스)이며, 대부분의 경우

에는 기본값을 사용하면 최적의 성능을 유지할 수 있습니다. 이 값은 60보다 크게 설정할 수 없습니다.

◆ 최대 nsrmmd 수는 스토리지 노드에서 동시에 실행할 수 있는 백업 프로세스 수를 제한하여 데이터 처리량을 높이는 데 사용할 수 있는 고급 설정입니다. 타겟 세션 또는 최대 세션을 변경하면 최대 nsrmmd 수가 MS/TS+4 수식에 따라 자동으로 조정됩

니다. 기본값은 12(FTD/AFTD) 및 14(DD Boost 디바이스)입니다.

참고: 세션 속성과 최대 nsrmmd 수를 동시에 수정하지 않는 것이 좋습니다. 이 값을 수정

해야 하는 경우 세션 속성을 먼저 조정하고 적용한 후에 최대 nsrmmd 수를 업데이트합

니다.

가상 디바이스 드라이브 수와 물리적 디바이스 드라이브 수아래 값은 Fibre Channel 포트 활용도 70%를 기준으로 합니다.

◆ LTO-3: 물리적 디바이스 2개마다 가상 디바이스 3개를 계획합니다.

◆ LTO-4: 물리적 디바이스마다 가상 디바이스 3개를 계획합니다.

포트:

같은 포트에서 이러한 각 테이프 드라이브의 성능은 연결된 디바이스 수에 따라 저하됩

니다. 예를 들어,

◆ 첫 번째 가상 드라이브에서 초당 150MB의 한계에 도달하는 경우

◆ 두 번째 가상 드라이브는 초당 100MB를 초과하지 않음

◆ 세 번째 가상 드라이브는 초당 70MB를 초과하지 않음


설정 조정

네트워크 최적화이 섹션의 내용은 다음과 같습니다.

◆ 51페이지의 "고급 구성 최적화"

◆ 51페이지의 "운영 체제 TCP 스택 최적화"

◆ 52페이지의 "고급 튜닝"

◆ 52페이지의 "예상 NIC 처리량 값"

◆ 52페이지의 "네트워크 지연"

◆ 54페이지의 "이더넷 이중화"

◆ 54페이지의 "방화벽"

◆ 54페이지의 "점보 프레임"

◆ 55페이지의 "정체 알림"

◆ 55페이지의 "TCP 버퍼"

◆ 56페이지의 "NetWorker 소켓 버퍼 크기"

◆ 57페이지의 "IRQ 밸런싱 및 CPU 선호도"

◆ 58페이지의 "인터럽트 조절"

◆ 58페이지의 "TCP 이동"

◆ 58페이지의 "이름 확인"

고급 구성 최적화

EMC 기술 노트 Configuring TCP Networks and Network Firewalls for EMC NetWorker에서는 멀티홈 시스템, 트렁킹과 같은 고급 구성 옵션에 대한 지침을 제공합니다.

기본 TCP 운영 체제 매개 변수는 성능을 최대화하기보다 기존 네트워크 인프라스트럭처

와의 호환성을 최대화하도록 튜닝됩니다.

운영 체제 TCP 스택 최적화

모든 사용 사례에 대해 운영 체제 TCP 스택을 최적화하기 위한 일반적인 규칙은 다음과 같습니다.

◆ 소프트웨어 흐름 제어를 해제합니다.◆ TCP 버퍼 크기를 늘립니다.◆ TCP 대기열 수준을 늘립니다.◆ 10GB NIC용 PCIeXpress를 사용합니다. 기타 입출력 아키텍처의 경우 대역폭이 충분

하지 않습니다.

PCIeXpress에 대한 자세한 내용은 18페이지의 "PCI-X 및 PCIeXpress 고려 사항:"에서 확인할 수 있습니다.

환경 기능에 따라 달라지는 규칙은 다음과 같습니다.

◆ 일부 운영 체제에는 내부 TCP 스택 자동 튜닝 기능이 있습니다. 이기종 환경이 아닌 경우 이 기능을 사용하면 원하는 결과를 얻을 수 있습니다. 그러나 이기종 또는 라우

팅된 환경에서는 TCP 자동 튜닝이 해제됩니다.

네트워크 최적화 51

설정 조정

◆ 가능하면 점보 프레임을 설정합니다. 점보 프레임에 대한 자세한 내용은 54페이지

의 "점보 프레임"에 나와 있습니다.

참고: 데이터 경로의 모든 네트워크 구성 요소가 점보 프레임을 처리할 수 있어야 합니다. 그렇지 않은 경우에는 점보 프레임을 설정하지 마십시오.

◆ TCP 하드웨어 이동은 정상적으로 작동하는 경우 유용합니다. 그러나 이로 인해 CRC 불일치가 발생할 수 있습니다. TCP 하드웨어 이동을 설정하는 경우 오류를 모니터링

하십시오.

◆ TCP 창 확장은 체인의 모든 네트워크 장비에서 지원하는 경우 유용합니다.

◆ 이기종 환경에서는 TCP 정체 알림으로 인해 문제가 발생할 수 있습니다. 따라서 단일 운영 체제 환경에서만 TCP 정체 알림을 설정해야 합니다.

고급 튜닝

고속 NIC용 IRQ 처리 기능은 가격이 매우 비싸지만 특정 CPU 코어를 선택함으로써 향상

된 성능을 제공할 수 있습니다. 구체적인 권장 사항은 CPU 아키텍처에 따라 달라집니다.

예상 NIC 처리량 값일반적인 NIC 처리량 값의 범위는 다음과 같습니다.

◆ 100Mb 링크 = 초당 6~8MB◆ 1Gb 링크 = 초당 45~65MB◆ 10Gb 링크 = 초당 150~350MB

값을 최적화하는 경우 고속 링크의 처리량을 다음과 같이 높일 수 있습니다.

◆ 100Mb 링크 = 초당 12MB◆ 1Gb 링크 = 초당 110MB◆ 10Gb 링크 = 초당 1,100MB10Gb 이더넷 링크의 이론적인 최대 처리량은 방향별로 초당 1.164GB입니다. 이 값은 비트를 바이트로 변환하고 최대 이더넷, IP 및 TCP 오버헤드를 제거하여 계산됩니다.

네트워크 지연

네트워크 TCP 지연이 길어지면 사용 가능한 링크 대역폭이 많아도 전체 처리량에는 좋지 않은 영향을 줍니다. 네트워크 호스트 간의 거리가 멀거나 홉 수가 많으면 전체 처리

량이 낮아질 수 있습니다.

네트워크 지연은 대역폭 사용 효율성에 큰 영향을 줍니다.

예를 들어 53페이지의 그림 12 및 53페이지의 그림 13에는 지연이 서로 다른 동일한 네트워크 링크의 백업 처리량이 나와 있습니다.


설정 조정

두 예제에서는 모두 최적화되지 않은 TCP 설정이 사용되었습니다.

그림 12 초당 10/100MB 네트워크의 지연

그림 13 1GB의 네트워크 지연


설정 조정

이더넷 이중화

반이중 모드에서 작동하는 네트워크 링크가 있으면 NetWorker 트래픽 흐름 성능이 떨어

집니다. 예를 들어 100Mb의 반이중 링크를 사용하는 경우 백업 성능이 초당 1MB 미만으

로 낮아집니다.

대부분의 운영 체제에서 이중화에 대한 기본 구성 설정은 IEEE802.3의 권장 사항에 따라 자동 협상됩니다. 그러나 자동 협상을 사용하려면 다음 조건이 충족되어야 합니다.

◆ 적절한 케이블 연결 ◆ 호환되는 NIC 어댑터 ◆ 호환되는 스위치

자동 협상을 사용하는 경우 링크가 반이중으로 작동할 수 있습니다.

자동 협상으로 인한 문제를 방지하려면 NIC에서 전이중 설정을 강제 적용하십시오. 링크 양쪽에 모두 전이중 설정을 강제 적용해야 합니다. 링크 한쪽에만 전이중 설정을 강제 적용하면 링크의 다른 쪽에서 자동 협상이 실패하게 됩니다.

방화벽

하드웨어 방화벽에서 입출력 경로에 대한 추가 계층을 적용하는 경우 네트워크 지연이 길어지고 전체 대역폭 사용량이 줄어듭니다.

따라서 백업 서버에서는 소프트웨어 방화벽을 사용하지 않는 것이 좋습니다. 백업 서버

는 많은 양의 패킷을 처리하므로 오버헤드가 많이 발생하기 때문입니다.

방화벽 구성 및 영향에 대한 자세한 내용은 기술 노트 Configuring TCP Networks and Network Firewalls for EMC NetWorker에 나와 있습니다.

점보 프레임

점보 프레임을 처리할 수 있는 환경에서는 점보 프레임을 사용하는 것이 좋습니다. 소스

와 컴퓨터 및 데이터 경로의 모든 장비가 점보 프레임을 처리할 수 있으면 MTU를 9KB로 늘립니다.

아래에는 Linux 및 Solaris 운영 체제용 예제가 나와 있습니다.

◆ Linux: ifconfig eth0 mtu 9000 up

◆ Solaris: 다음 명령을 사용하여 nxge 디바이스에 대해 점보 프레임을 구성합니다.

ndd -set /dev/nxge<#> accept-jumbo 1

여기서 <#>은 드라이버 인스턴스 번호로 바꿉니다.

참고: 다음 디바이스의 인스턴스 번호를 확인하려면 nxge /etc /path_to_inst 명령을 실행합니다.


설정 조정

정체 알림

이 섹션에서는 정체 알림 알고리즘을 해제하는 방법을 설명합니다.

◆ Windows 2008 R2 전용:

1. 다음과 같이 선택적 정체 알림 알고리즘을 해제합니다.

C:\> netsh interface tcp set global ecncapability=disabled

2. Windows에서는 고급 TCP 알고리즘을 사용하면 최상의 결과를 얻을 수 있습니다. 그러나 네트워크 변환의 양쪽에서 모두 협상을 사용할 수 없으면 고급 TCP 알고

리즘을 해제합니다.

C:\> netsh interface tcp set global congestnprovider=ctcp

◆ Linux:

1. 비표준 알고리즘을 확인합니다.

cat /proc/sys/net/ipv4/tcp_available_congestion_control

2. ECN을 해제합니다.

echo 0 >/proc/sys/net/ipv4/tcp_ecn

◆ Solaris:

TCP Fusion이 있는 경우 해제합니다.

set ip:do_tcp_fusion = 0x0

TCP 버퍼

고속 네트워크 인터페이스의 경우 TCP 수신/송신 버퍼 크기를 늘립니다.

◆ Linux:

Linux에서 TCP 버퍼 설정을 수정하려면 다음 매개 변수를 /etc/sysctl.conf 파일에 추가한 다음 /sbin/sysctl -p 명령을 실행합니다.

net.core.rmem_default = 262144net.core.wmem_default = 262144net.core.rmem_max = 16777216net.core.wmem_max = 16777216net.ipv4.tcp_rmem = 8192 524288 16777216net.ipv4.tcp_wmem = 8192 524288 16777216

권장 RPC 값을 설정합니다.

sunrpc.tcp_slot_table_entries = 64

동적 TCP 창 확장을 설정할 수도 있습니다. 이렇게 하려면 데이터 경로에 호환 장비가 필요합니다.

sysctl -w net.ipv4.tcp_window_scaling=1

◆ Solaris:

tcp_max_buf 10485760 tcp_cwnd_max 10485760 tcp_recv_hiwat 65536 tcp_xmit_hiwat 65536


설정 조정

◆ AIX

매개 변수의 값이 권장 값보다 작으면 /etc/rc.net에서 값을 수정합니다. 커널의 수신 소켓 대기열에서 시스템이 버퍼링할 수 있는 바이트 수는 다음과 같습니다.

no -o tcp_recvspace=524288

애플리케이션이 송신 호출에서 차단되기 전에 커널에서 버퍼링할 수 있는 바이트 수는 다음과 같습니다.

no -o tcp_sendspace=524288

◆ Windows:

• Windows 운영 체제에서 유지하는 기본 버퍼 크기를 사용하면 충분합니다.

• 다음과 같이 레지스트리 항목을 설정합니다.

AdditionalCriticalWorkerThreads: DWORD=10

• NIC 드라이버가 드라이버 레벨에서 여러 버퍼 또는 대기열을 생성할 수 있으면 드라이버 레벨에서 NIC 드라이버를 설정합니다. 예를 들어 Intel 10Gb NIC 드라이

버의 경우 기본적으로 RSS 대기열이 2로 설정되며 최적의 성능을 위한 권장 값은 16입니다.

• Windows 2008 서버에는 TCP 스택을 자동으로 튜닝하는 방법이 도입되었습니다. 라우터, 스위치 등의 데이터 영역에 있는 네트워크 디바이스 또는 LAN의 서버가 TCP 창 확장을 지원하지 않으면 백업이 실패할 수 있습니다. 백업 실패를 방지하

고 NetWorker 작업을 최적의 상태로 수행하려면 Microsoft 핫픽스 KB958015를 Windows 2008 Server에 적용하고 자동 튜닝 레벨 값을 highly restricted로 설정합

니다.

1. 현재 TCP 설정을 확인합니다.C:\> netsh interface tcp show global

2. 필요한 경우 Windows TCP 수신 측 확장 자동 튜닝 레벨을 제한합니다.

C:\> netsh interface tcp set global autotuninglevel=highlyrestricted

참고: 핫픽스 KB958015를 적용하지 않는 경우에는 자동 튜닝 레벨을 highly restricted가 아닌 disabled로 설정해야 합니다.

NetWorker 소켓 버퍼 크기

NetWorker 7.6.x 이하에서 큰 TCP 송신/수신 창을 사용하도록 강제 적용하려면 NetWorker 시작 스크립트에 다음 항목을 포함합니다.

NSR_SOCK_BUF_SIZE=65536export NSR_SOCK_BUF_SIZE

◆ 1GB 네트워크에 대한 최적의 TCP 소켓 버퍼는 64KB입니다.

◆ 10GB 네트워크에 대한 최적의 TCP 소켓 버퍼는 256KB입니다. NetWorker 시작 스크

립트에 다음 항목을 추가합니다.

NSR_SOCK_BUF_SIZE=262144


설정 조정

참고: NetWorker 8.0 이상에서는 NetWorker 소켓 버퍼 크기를 설정하지 않아도 됩니다. 소켓 버퍼 크기는 소프트웨어에서 구축되며 256KB의 소켓 버퍼 크기를 사용하도록 설정됩니다.

IRQ 밸런싱 및 CPU 선호도

여러 개의 1Gb 인터페이스 또는 하나의 10Gb 인터페이스를 사용하는 고속 네트워크 인터페이스의 경우 특정 CPU 코어 처리에 대한 바인딩 및 IRQ 밸런싱을 해제하는 것이 효율적입니다.

참고: 일반적으로는 물리적 CPU당 하나의 코어만이 NIC 인터럽트를 처리해야 합니다. CPU보다 NIC가 많을 때만 CPU당 여러 코어를 사용하십시오. 그러나 전송 및 수신은 예외 없이 항상 같은 CPU에서 처리해야 합니다.

아래에는 Linux 및 Solaris 운영 체제용 예제가 나와 있습니다.

◆ Linux:

1. IRQ 밸런싱을 해제하고 CPU 선호도를 수동으로 설정합니다.

service irqbalance stopchkconfig irqbalance off

2. eth0 인터페이스에 대한 CPU 선호도를 튜닝합니다.

grep eth0 /proc/interrupts

3. 선호도는 최고 선호도에서 최저 선호도순으로 튜닝합니다. 예를 들어,

echo 80 > /proc/irq/177/smp_affinityecho 40 > /proc/irq/166/smp_affinity

SMP 선호도는 IO-APIC가 설정된 디바이스 드라이버에 대해서만 작동합니다. 디바이스의 IO-APIC 호환성은 cat /proc/interrupts를 사용하거나 디바이스 설명서

를 참조하여 확인할 수 있습니다.

◆ Solaris:

CPU당 코어 하나만 인터럽트합니다. 예를 들어 CPU와 CPU당 코어가 각각 4개인 시스템의 경우 다음 명령을 사용합니다.

psradm -i 1-3 5-7 9-11 13-15

추가 튜닝은 시스템 아키텍처에 따라 달라집니다.

아래에는 T1/T2 CPU가 장착된 Solaris 시스템의 올바른 설정 예제가 나와 있습 니다.

ddi_msix_alloc_limit 8 tcp_squeue_wput 1 ip_soft_rings_cnt 64 ip_squeue_fanout 1

일부 NIC 드라이버는 피크 CPU 사용량을 줄이기 위해 인터럽트 속도를 인위적으로 제한

합니다. 그러나 이 경우 도달 가능한 최대 처리량도 제한됩니다. NIC 드라이버가 "인터럽

트 조절(Interrupt moderation)"로 설정된 경우 최적의 네트워크 처리량을 위해 인터럽트 조절을 해제하십시오.


설정 조정

인터럽트 조절

10GB 네트워크에서 Windows를 사용하는 경우에는 네트워크 성능을 개선할 수 있도

록 네트워크 어댑터에 대해 인터럽트 조절(Interrupt moderation)을 해제하는 것이 좋습

니다.

TCP 이동

NIC가 낮은 레벨에서 TCP 패킷을 처리할 수 있는 시스템의 경우에는 다음을 위해 운영 체제에서 TCP 이동을 설정합니다.

◆ 전체 대역폭 활용도 향상

◆ 시스템에 대한 CPU 로드 감소

참고: 이동 기능을 제공하는 모든 NIC가 표준을 완전히 준수하는 것은 아닙니다.

◆ Windows 2008 서버의 경우 다음 명령을 사용하여 TCP 이동을 설정합니다.

C:\> netsh interface tcp set global chimney=enabled

◆ Windows 2008 R2 서버의 경우에는 추가 속성과 함께 다음 명령을 사용하여 TCP 이동을 설정합니다.

C:\> netsh interface tcp set global dca=enabledC:\> netsh interface tcp set global netdma=enabled

◆ 백업 세션이 정지되거나, RPC 오류로 인해 실패하거나, 다음과 같은 연결 재설정

(CRC) 오류로 인해 실패하는 등의 문제가 나타나는 이전 세대 NIC 카드의 경우에는 TCP 이동을 해제합니다.

피어가 연결을 재설정했습니다.

참고: TCP 이동은 정상적으로 작동하는 경우 유용합니다. 그러나 이로 인해 CRC 불일치

가 발생할 수 있습니다. TCP 하드웨어 이동을 설정하는 경우 오류를 모니터링하십시오.

이름 확인

NetWorker Server는 운영 체제의 이름 확인 기능에 크게 의존함

DNS 서버의 경우 다음 중 하나를 구성하는 경우 발생하는 성능 문제를 방지하기 위해 DNS 서버에 대한 짧은 지연 액세스를 설정합니다.

◆ 로컬 DNS 캐시

또는

◆ 기본 DNS 서버로부터의 영역 전송 기능을 제공하는 로컬 비신뢰 DNS 서버

로컬 호스트 이름 확인 시 DNS 조회가 수행되지 않도록 하려면 시스템의 각 IP 주소에 대해 할당된 서버 이름 및 호스트 이름이 호스트 파일에 정의되어 있는지 확인하십시오.


설정 조정

스토리지 최적화 59

스토리지 최적화이 섹션에서는 NetWorker 서버 및 스토리지 노드 디스크 최적화를 위한 설정에 대해 설명합니다.

NetWorker 서버 및 스토리지 노드 디스크 쓰기 지연

이 섹션에서는 NetWorker 서버 및 스토리지 노드 쓰기 지연의 요구 사항에 대해 설명합

니다. NetWorker 서버 및 스토리지 노드의 /nsr에 대한 쓰기 지연은 전체 대역폭보다 /nsr을 호스팅하는 스토리지에 더욱 중요하게 작용합니다. NetWorker가 내부 데이터베이스 액세스를 위해 작은 무작위 입출력을 매우 많이 사용하기 때문입니다. 59페이지의 표 7에는 NetWorker 백업 작업 중의 성능에 대한 디스크 쓰기 지연의 영향이 나와 있습니다.

참고: 지연 시간에 부정적 영향을 미칠 수 있는 기타 기술 또는 동기식 복제 기술은 사용

하지 마십시오.

권장 서버 및 스토리지 노드 디스크 설정

이 섹션에서는 NetWorker 서버 및 스토리지 노드 디스크 성능을 최적화하기 위한 권장 사항을 제공합니다.

◆ NetWorker 서버에 대한 로드가 늘어나면(백업 중에 수행되는 병렬 세션 수가 100 개를 초과함) NetWorker 데이터베이스 호스팅 전용 고속 디스크 디바이스를 지정합

니다.

◆ NetWorker 서버용으로 구성된 디스크 스토리지에는 RAID-10을 사용합니다.

◆ 서버 병렬 처리 수가 병렬 세션 400개보다 많은 대규모 NetWorker 서버의 경우에는 NetWorker 서버에서 사용되는 파일 시스템을 분할합니다. 예를 들어 /nsr 폴더를 단일 마운트 지점에서 다음에 대한 여러 마운트 지점으로 분할합니다.

/nsr

/nsr/res

/nsr/index

/nsr/mm

표 7 디스크 쓰기 지연 결과 및 권장 사항

밀리초 (ms) 단위의 디스크 쓰기 지연 성능에 미치는 영향 권장 사항

25ms 이하 • 안정적인 백업 성능

• 최적의 백업 속도

예

50ms • 백업 성능 저하(NetWorker 서버가 데이터베이스 업데이트를 임계치(throttle) 조절하도록 강제 적용됨)

• MMC 업데이트 지연 및 실패

아니요

100ms 세이브 그룹 및 세션 실패 아니요

150~200ms • NetWorker 데몬 시작 지연

• 백업 성능 불안정

• 쓰기 작업을 위한 볼륨이 준비되지 않음

• 프로세스 통신 불안정

아니요

설정 조정

◆ NetWorker 서버에서 수행하는 NDMP 백업의 경우 대규모 임시 파일 처리를 수행할 수 있도록 /nsr/tmp 폴더에 대해 별도의 위치를 사용합니다.

◆ 모든 마운트 지점이 같은 물리적 위치에 있더라도 운영 체제를 통해 병렬 파일 시스

템 입출력을 처리합니다. 운영 체제가 NetWorker 소프트웨어보다 병렬 파일 시스템 입출력을 더 효율적으로 처리합니다.

◆ AFTD용 디스크 스토리지에는 RAID-3을 사용합니다.

◆ 바이러스 백신 소프트웨어에 대해서는 NetWorker 데이터베이스 스캔을 해제합

니다. 바이러스 백신 소프트웨어가 /nsr 폴더를 스캔할 수 있는 경우 빈번한 파일 열기/닫기 요청으로 인해 성능 저하, 시간 초과 또는 NetWorker 데이터베이스 손상

이 발생할 수 있습니다. 또한 바이러스 백신의 제외 목록에는 AFTD(Advanced File Type Device)에 사용되는 NetWorker 스토리지 노드 위치가 포함되어야 합니다.

제외 목록이 이전에 액세스한 파일의 스캔을 건너뛰는 경우 파일 액세스 중의 모든 위치가 포함된다면 특정 위치에 대해 바이러스 백신 스캔을 해제하는 것이 효과적이지 않을 수 있습니다. 해당 공급업체에 문의하여 바이러스 백신 소프트웨어의 업데이트된 버전을 받으십시오.

◆ 파일 캐싱의 경우 적극적인 파일 시스템 캐싱을 사용하면 다음과 같은 커밋 문제가 발생할 수 있습니다.

• NetWorker 서버: 모든 NetWorker 데이터베이스(nsr\res, nsr\index, nsr\mm)가 영향을 받을 수 있습니다.

• NetWorker 스토리지 노드: AFTD(Advanced File Type Device)를 사용하도록 구성된 경우

지연된 쓰기 작업을 해제하고 드라이버 플러시 및 Write-Through 명령을 대신 사용합니다.

◆ NetWorker는 커밋된 입출력을 사용하므로, NetWorker 서버에 대한 디스크 지연 고려 사항은 일반적인 서버 애플리케이션보다 높습니다. NetWorker 내부 데이터베이스

에 대한 각 쓰기를 확인 및 플러시한 후에 다음 쓰기를 시도해야 합니다. 이는 내부 데이터베이스의 데이터 손실 가능성을 방지하기 위한 것입니다. 스토리지가 복제 또는 미러링되는 경우의 /nsr에 대한 고려 사항은 다음과 같습니다.

• 소프트웨어 기반 복제를 사용하는 경우 입출력 처리량에 계층이 더 추가되며 예기치 않은 NetWorker 동작이 수행되므로 소프트웨어 기반 복제는 사용하지 않습

니다.

• 하드웨어 기반 복제 시의 기본 방법은 쓰기 작업을 추가로 지연시키지 않는 비동

기식 복제입니다.

• 장거리 링크 또는 지연이 보장되지 않는 링크에 대해서는 동기식 복제를 사용하

지 않습니다.

• SAN에서는 로컬 복제가 12km로 제한되며, 거리가 더 긴 경우 특수한 처리가 필요합니다.

• TCP 네트워크는 지연을 보장하지 않으므로 동기식 복제에는 TCP 네트워크를 사용하지 않습니다.

• 각 하드웨어 구성 요소로 인해 지연이 추가될 때 홉 수를 고려합니다.


4장

성능 테스트

이 장에서는 bigasm, uasm 등의 NetWorker 프로그램을 비롯하여 사용 가능한 툴을 통해 병목 현상을 테스트하고 파악하는 방법을 설명합니다. 이 장에서 다루는 내용은 다음과 같습니다.

◆ 증상 확인 ............................................................................................................... 62◆ 성능 모니터링 ........................................................................................................ 62◆ 일반 FTP 테스트를 사용하여 병목 현상 확인 .......................................................... 63◆ dd를 사용하여 설정 성능 테스트............................................................................ 63◆ bigasm 및 uasm을 사용하여 디스크 성능 테스트 ................................................... 64

성능 테스트 61

성능 테스트

증상 확인백업 성능 불량의 원인을 결정하기 위한 고려 사항은 다음과 같습니다.

◆ 전체 백업 시간 동안 성능이 일정한지 여부

◆ 다른 시간에 시작했을 때 백업 성능이 더 우수한지 여부

◆ 클라이언트의 모든 세이브 세트에서 백업 성능이 일정한지 여부

◆ 특정 스토리지 노드를 사용하는 유사한 시스템 구성의 모든 클라이언트에서 백업 성능이 일정한지 여부

◆ 같은 서브넷에 있는 유사한 시스템 구성의 모든 클라이언트에서 백업 성능이 일정한

지 여부

◆ 유사한 시스템 구성 및 애플리케이션을 사용하는 모든 클라이언트에서 백업 성능이 일정한지 여부

여러 매개 변수를 사용할 때의 클라이언트 성능을 관찰합니다. 백업 속도가 일정하지 않은 경우 소프트웨어 또는 펌웨어에 문제가 있을 수 있습니다.

각 NetWorker 클라이언트에 대해 다음 사항을 확인합니다.

◆ 전체 백업 시간 동안 성능이 일정한지 여부

◆ 백업을 다른 시간에 시작했을 때 성능이 달라지는지 여부

◆ 특정 스토리지 노드를 사용하는 모든 클라이언트에서 백업 성능이 일정한지 여부

◆ 클라이언트의 모든 세이브 세트에서 백업 성능이 일정한지 여부

◆ 같은 서브넷에 있는 모든 클라이언트에서 백업 성능이 일정한지 여부

◆ 유사한 운영 체제, 서비스 팩 및 애플리케이션을 사용하는 모든 클라이언트에서 백업 성능이 일정한지 여부

◆ 저장 중에 백업 성능이 개선되는지 여부

이를 비롯해 이와 유사한 상황을 확인하면 특정 성능 문제를 파악하는 데 도움이 됩니다.

성능 모니터링다음과 같은 기본 성능 모니터링 툴을 사용하여 입출력, 디스크, CPU 및 네트워크 성능을 모니터링합니다.

◆ Windows: Perfmon

◆ UNIX: iostat, vmstat 또는 netstat 명령

백업 전/중/후에 비정상적인 작업이 수행되는지 살펴보면 디바이스에서 리소스를 과도

하게 사용하는지를 확인할 수 있습니다.

이러한 툴을 사용하여 일정 기간 동안의 성능과 NetWorker를 포함한 각 애플리케이션에

서 사용하는 리소스를 명확하게 파악할 수 있습니다.

다른 애플리케이션에 네트워크를 과도하게 사용하여 백업 속도가 느려지는 것으로 확인된 경우 백업 스케줄을 변경하면 해당 문제를 해결할 수 있습니다.

CPU 사용량은 CPU 성능 자체가 부족해서가 아니라 외부 입출력을 대기할 때 높아지는 경우가 많습니다. 이는 시스템 공간과 사용자 공간 내의 높은 CPU 사용량을 비교하여 확인할 수 있습니다.


성능 테스트

Windows에서는 지연된 프로시저 호출에 시간이 오래 걸리면 디바이스 드라이버에 문제

가 있는 경우가 많습니다.

일반 FTP 테스트를 사용하여 병목 현상 확인NetWorker 구성 요소를 사용하지 않고 일반 FTP 테스트를 통해 네트워크나 테이프 디바

이스에서 병목 현상이 발생하는지를 확인할 수 있습니다.

1. NetWorker 클라이언트에서 큰 데이터 파일을 생성한 다음 FTP를 사용하여 스토리지 노드로 보냅니다.

2. 파일 전송에 걸린 시간을 기록해 둡니다.

3. 2단계에서 기록해 둔 시간을 현재 백업 성능과 비교합니다.

• FTP의 속도가 백업 속도보다 훨씬 빠르면 테이프 디바이스에서 병목 현상이 발생

하는 것일 수 있습니다.

• FTP와 백업의 속도가 비슷하면 네트워크에서 병목 현상이 발생하는 것일 수 있습

니다.

4. 활성 FTP 전송과 수동 FTP 전송을 사용하여 결과를 비교합니다. NetWorker 백업 성능

은 기본 네트워크의 기능과 NetWorker 소프트웨어에서 사용하는 네트워크 패킷에 의해 크게 영향을 받습니다.

전송 속도에 큰 차이가 있거나 한 유형의 FTP 전송에서 급격한 속도 변화가 있다 면 TCP 패킷 재조립을 수행하는 네트워크 구성 요소가 있을 수 있다는 의미입니다. 이 때문에 모든 물리적 구성 요소가 양방향 이중화 모드임에도 링크가 단방향 이중화 모드로 수행될 수 있습니다.

참고: 로컬 볼륨을 사용하여 ftp 테스트용 파일을 생성 및 전송하지 말고 백업 볼륨을 사용하십시오.

dd를 사용하여 설정 성능 테스트NetWorker 구성 요소를 사용하지 않고 일반 dd 테스트를 사용하여 디바이스 처리량을 제조업체에서 제시하는 처리량과 비교할 수 있습니다.

1. 스토리지 노드에서 큰 데이터 파일을 생성한 다음 dd를 사용하여 타겟 디바이스로 보냅니다.

date; dd if=/tmp/5GBfile of=/dev/rmt/0cbn bs= 1MB; date

2. 파일 전송에 걸린 시간을 기록한 다음 현재 테이프 성능과 비교합니다.

일반 FTP 테스트를 사용하여 병목 현상 확인 63

성능 테스트

bigasm 및 uasm을 사용하여 디스크 성능 테스트bigasm 및 uasm 지침은 NetWorker 성능을 확인하는 데 사용되는 NetWorker 기반 테스트

입니다.

bigasm 지침

bigasm 지침은 특정 크기의 파일을 생성한 다음 네트워크 또는 SCSI 접속을 통해 파일을 전송합니다. 파일은 테이프 또는 다른 타겟 디바이스에 기록됩니다. bigasm 지침은 메모

리에서 바이트 스트림을 생성한 다음 디스크를 액세스하지 않아도 되도록 타겟 디바이

스에 해당 스트림을 저장합니다. 따라서 디스크 액세스를 무시하고 NetWorker 클라이언

트, 네트워크 및 테이프 디바이스의 속도를 손쉽게 테스트할 수 있습니다.

bigasm 지침을 만들고 매우 큰 세이브 세트를 생성합니다.

bigasm 지침은 디스크 액세스를 무시하고 클라이언트, 네트워크 및 테이프의 성능을 테스트합니다.

uasm 지침

uasm 지침은 최대 속도로 디스크에서 읽기를 수행하여 디스크 기반 병목 현상을 파악합

니다. 예를 들어,

uasm –s filename > NUL

uasm 지침은 디스크 읽기 속도를 테스트하며, null 디바이스에 데이터를 기록하여 디스

크 기반 병목 현상을 파악할 수 있습니다.


성능 최적화 계획 가이드 - dell emc...networker 소프트웨어는 전체 데이터...

Documents