4 VTCS 대시보드 사용

”VTCS 대시보드 사용”은 기본적으로 MVC 및 VTC 보고서 검토에 대한 것입니다. 가상 테이프 구성의 기본과 부속 부분은 VTSS, VTD, VTV, RTD 및 MVC이므로 이 모두가 정상적으로 작동하는지 여부를 확인하는 것이 여러분이 수행하는 주요 일간 및 주간 업무라는 사실은 새삼스러운 일이 아닙니다.

가상 테이프 상태 확인(일간)

VTSS를 니어라인 ACS의 가상 상대로, VTD를 니어라인 실제 테이프 드라이브의 가상 상대로, VTV를 니어라인 볼륨의 가상 상대로 간주하면 모든 VTSS, VTD 및 VTV가 정상적으로 작동하는지 확인하는 것이 중요한 이유를 쉽게 알 수 있을 것입니다.

가상 테이프 상태를 확인하려면 다음과 같이 하십시오.

Display VTSS 명령을 입력합니다.

테이블 4-1과 유사한 결과가 표시됩니다.

테이블 4-1 Display VTSS의 출력 예 - 양호한 VTSS 상태

VTSS NAME	CAPACITY(MB)	DBU	HI AMT	LOW AMT	VTV COUNT	MX MT	MN MT	DEF ACS	AUTO MIG	STATE
HBVTSS16	56,209	55	80	60	2440	6	3	02	-	ONLINE
HBVTSS17	56,209	50	80	60	2180	6	3	02	-	ONLINE
HBVTSS18	56,209	52	80	60	2288	6	3	01	-	ONLINE
HBVTSS19	93,184	45	80	60	1900	6	3	01	-	ONLINE

테이블 4-1은 4개의 ”정상적으로 작동하는” VTSS의 상태를 보여줍니다.

우선 모든 VTSS가 온라인이며, 이는 일반적으로 적절한 상태입니다.
LAMT는 모두 60이고 HAMT는 모두 80이며, 이는 VTSS 사용량 최적화 및 효과적인 자동 마이그레이션을 촉진하는 데 적절한 범위입니다.
DBU는 모두 HAMT보다 낮은데 이는 자동 마이그레이션이 시작되기 전에 VTSS에서 증가할 공간이 여전히 있음을 의미합니다. 가상 테이프에 대한 투자를 최적화하기 위해 이러한 VTSS에 더 많은 작업 경로를 지정하는 것도 고려할 수 있습니다.
각 VTSS에 8개의 RTD가 연결되어 있다고 가정해 보겠습니다. MX MT(최대 마이그레이션 작업)는 6으로 설정되어 있고 MN MT(최소 마이그레이션 작업)은 3으로 설정되어 있는데 이는 적절한 설정입니다. 최대 6개는 2개의 RTD가 회수/확보를 위해 남아 있고, 최소 3개는 적은 수의 마이그레이션이 갑자기 시작될 경우에도 로드를 처리할 수 있는 작업 여유가 있도록 해줍니다.

Display VTSS가 별로 좋게 보이지 않는다면 어떻게 될까요? 아마도 테이블 4-2와 유사할 수 있습니다.

테이블 4-2 Display VTSS의 출력 예 - 주요 작동 문제가 있는 VTSS

VTSSNAME	CAPACITY(MB)	DBU	HI AMT	LOW AMT	VTV COUNT	MX MT	MN MT	DEF ACS	AUTO MIG	STATE
HBVTSS16	56,209	90	80	60	27,888	4	2	02	-	ONLINE
HBVTSS17	56,209	92	80	60	28,974	4	2	02	-	ONLINE
HBVTSS18	56,209	90	80	60	22,005	4	2	01	-	ONLINE
HBVTSS19	93,184	92	80	60	26,009	4	2	01	-	ONLINE

테이블 4-2는 몇 가지 주요 작동 문제가 있는 4개의 VTSS 상태를 보여줍니다.

적어도 모두 온라인입니다. 그렇지 않은 경우 오프라인이거나 유지 관리 모드가 되어야 하는 이유를 알지 못한다면 몇 가지 Vary VTSS 명령을 입력하여 온라인으로 전환합니다.
DBU가 모두 너무 높습니다. 90이 넘는 범위는 VTSS가 VTV를 자동 마이그레이션하는 데 어려움이 있으며, 이것은 다음과 같은 원인으로 인한 당연한 결과입니다.
각 VTSS에 8개의 RTD가 연결되어 있다고 가정해 보겠습니다. MX MT(최대 마이그레이션 작업)는 4로 설정되어 있고 MN MT(최소 마이그레이션 작업)는 2로 설정되어 있는데 이는 현재 마이그레이션 로드에 대해 약간 부족한 것이 사실입니다.

이 문제를 해결하려면 단계 2로 이동하십시오.

단계 1에 나온 것이 만족스럽지 않다면 작동 매개변수를 조정합니다.

우선, 더 많은 마이그레이션 작업을 진행합니다.
```
set migopt vtss(vtssname) maxmig(8) minmig(8) high(70) low(40) 
```
이제 모든 RTD가 모든 VTSS에서 마이그레이션에 완전히 투입되었습니다. DBU를 통제할 수 있을 때까지 이대로 진행한 다음 최대값 6, 최소값 3과 같이 돌아갑니다. AMT도 하한 40, 상한 70으로 변경했습니다. 그러면 문제가 발생하지 않으며, 다음 번에는 마이그레이션이 더 일찍 시작되고 버퍼가 더 낮은 DBU로 회복됩니다.

그런 다음 Display VTD를 입력하여 시스템의 VTD를 파악합니다.

테이블 4-3은 Display VTD 출력의 예를 보여줍니다.

테이블 4-3 Display VTD의 출력 예 - 올바르게 작동

DRIVE LOCATION VTV STATUS

A800

HBVTSS16

X00778

MOUNTED

A801

HBVTSS16

X00775

MOUNTED

A802

HBVTSS16

-

AVAILABLE

A803

HBVTSS16

-

AVAILABLE

다시 한 번 테이블 4-3에서 일부 VTD가 사용 중이고 다른 일부는 사용할 준비가 되어 있는 양호한 상태가 됩니다.

모든 VTD가 마운트된 VTV를 표시한다면 어떻게 될까요? 이는 바람직하지 않습니다. 그 이유는 사용 가능한 드라이브가 없을 경우 작업 할당 실패의 위험이 있기 때문입니다. 단계 2에서 발생한 것과 유사한 문제가 원인이라면 이를 받아들이고 이후부터 VTD가 데이터의 유입을 더욱 잘 처리할 수 있도록 작업 로드를 조정하십시오. 하지만 장기적인 문제라면 더 많은 VTSS가 필요하거나 더 많은 용량과 더 많은 VTD를 가진 VTSS로 업그레이드해야 할 수 있습니다.
이제 Display SCRATCH 명령을 입력하여 충분한 스크래치 VTV를 보유하고 있는지 알아볼 때입니다. 그러면 테이블 4-4와 유사한 출력이 표시됩니다.

테이블 4-4 Display SCRATCH의 출력 예

SUBPOOL-NAME SCRATCH-COUNT

VIR000

14,364

VIR0002

13,582

VIRTUAL

19,132

VIRTUAL1

9,905

테이블 4-4에서 보이는 것은 HSC 하위 풀에 대한 VTV 스크래치 수입니다. VTV에 대해 HSC 하위 풀을 사용하지 않는 경우 시스템에 정의된 모든 VTV에 대한 VTV 스크래치 수를 보게 됩니다. 일부 사용 가능한 스크래치 VTV가 있다면 스크래치 수에 대한 좋거나 나쁜 수는 없습니다. ”사용 가능한 스크래치의 알맞은 수”는 조직의 필요와 작업 로드에 따라 달라집니다.

테이블 4-4에서 각 하위 풀에 대해 사용 가능한 스크래치가 50 이하로 나타날 경우 약간 문제가 될 수 있습니다. 이 경우 다음 중 하나 이상의 작업을 수행할 수 있습니다.
- 최신이 아닌 데이터가 있는 VTV를 스크래치하여 VTV volser 확보. 이 작업은 시스템에 충분한 총 VTV가 있지만 사용 가능한 충분한 스크래치 볼륨이 없는 경우 수행합니다.
  
  실제로는 여러분이 스크래치를 수행하지 않으며 TMS에서 수행해야 할 작업이고, 초기 구성에서 TMS에 VTV volser를 정의했어야 합니다. 이렇게 정의되지 않은 경우 돌아가서 그렇게 하십시오. 또한 VTCS CONFIG 명령문을 통해 VTV 범위를 추가하고 TMS에 새 범위를 정의하는 것을 잊어버렸을 수 있으므로 돌아가서 해당 문제를 해결하십시오. 이 내용은 모두 ELS 설치에 설명되어 있습니다.
  
  하지만 TMS에서 VTV를 스크래치로 표시하는 것은 해결책의 일부에 불과합니다. 함께 수행해야 하는 작업은 VSM의 누군가가 VTV 데이터를 최신이 아님(따라서 쓰기 가능)으로 표시하고, VTSS 상주 VTV의 경우 버퍼에서 삭제해야 합니다.
  
  VTV 데이터를 실제로 삭제하는 것은 중대한 결정(데이터가 없어짐)이므로 신중한 판단을 내리고 ”필요에 따른” 작업이 되어야 합니다. 이 경로를 따를 경우 "요청식 MVC 공간 재생 수행"을 참조하십시오.
- POOLPARM 또는 VOLPARM을 사용하여 VTV 추가. 이 작업은 차선의 옵션이며, 최신이 아닌 데이터가 있는 VTV가 실제로 없을 때 수행합니다. POOLPARM 또는 VOLPARM만이 아니라 적절한 TMS 정의 등도 수행해야 합니다. 이 내용도 모두 ELS 설치에 설명되어 있습니다.
- 추가 VTV를 정의할 수 있을 때까지 임시로 테이프 작업을 니어라인 HSC 처리로 재지정하도록 TAPEREQ 명령문 또는 SMS 루틴 변경. 원래 VSM으로 전송하려고 했던 데이터를 니어라인 테이프로 전송해야 하고 정리 작업이 만만치 않으므로 이 작업은 가장 권장되지 않는 옵션입니다. 그래도 사용 가능한 니어라인 리소스가 있고 데이터를 스크래치 볼륨에 즉시 기록해야 한다면 이 작업을 (임시로) 수행할 수밖에 없습니다.

DRIVE	LOCATION	VTV	STATUS
A800	HBVTSS16	X00778	MOUNTED
A801	HBVTSS16	X00775	MOUNTED
A802	HBVTSS16	-	AVAILABLE
A803	HBVTSS16	-	AVAILABLE

SUBPOOL-NAME	SCRATCH-COUNT
VIR000	14,364
VIR0002	13,582
VIRTUAL	19,132
VIRTUAL1	9,905

니어라인 테이프 상태 확인(일간)

"가상 테이프 상태 확인(일간)"에서는 시스템의 VTSS, VTD 및 VTV가 정상적으로 작동하는지 확인하는 것이 얼마나 중요한지에 대해 설명합니다.

VTV가 마이그레이션되고 회수되는 장소이며 일부 MVC 공간 확보가 백그라운드에서 진행되는 VSM의 니어라인 구성 요소(RTD 및 MVC)임을 고려하면 이 영역도 철저한 주의가 요구되는 부분임을 동의할 것입니다.

니어라인 테이프 상태를 확인하려면 다음과 같이 하십시오.

Display RTD를 입력합니다.

양호한 상태는 테이블 4-5와 유사합니다.

테이블 4-5 VT Display RTD 명령의 출력 예 - 모두 양호

RTD	STATUS	MOUNT	ALLOC	HOST	VTSS
B200	ONLINE/FREE	-	-	-	HBVTSS16
B201	ONLINE/FREE	-	-	-	HBVTSS16
0B79	ONLINE/FREE	-	-	-	HBVTSS16
0B7A	RECALL VTV	DMV051*	DMV051	EC20	HBVTSS16
1600	MVS1 :MIGRATE	-	-	-	-
1601	MVS1 :MIGRATE	-	-	-	-

테이블 4-5에서는 마이그레이션, 회수 및 새로운 작업을 위해 사용 가능한 RTD의 균형이 잘 맞으므로 모든 것이 순조롭게 진행되지만, 테이블 4-6에서는 그렇지 않습니다.

테이블 4-6 VT Display RTD 명령의 출력 예 - 문제가 있는 RTD

RTD	STATUS	MOUNT	ALLOC	HOST	VTSS
B200	MVS1 :MIGRATE	-	-	-	-
B201	MVS1 :MIGRATE	-	-	-	-
0B79	MVS2 :MIGRATE	-	-	-	-
0B7A	MVS2 :MIGRATE	-	-	-	-
1600	MVS1 :MIGRATE	-	-	-	-
1601	MVS1 :MIGRATE	-	-	-	-

테이블 4-6이 단계 2에서 수행된 일종의 긴급 조치 결과라면 상황이 정상화될 때까지 기다리는 수밖에 없습니다. 하지만 사용 가능한 다른 RTD(예를 들어, MVS 및 VSM와 수동으로 공유 중인 RTD)가 있다면 MVS에 오프라인으로 전환하고 Vary RTD를 사용하여 VTCS에서 사용할 수 있도록 만듭니다.

그런 다음, Display MVCPool 명령을 사용하여 MVC의 상황을 확인합니다.

그림 4-1은 지정된 MVC 풀 이름이 없으므로 모든 시스템의 MVC에 대한 정보가 표시되는 Display MVCPool 출력의 예를 보여줍니다.

그림 4-1 Display MVCPool의 출력 예(지정된 풀 이름 없음)

설명 그림 4-1 Display MVCPool의 출력 예(지정된 풀 이름 없음)

그림 4-1은 MVC 모음이 양호한 조건임을 보여줍니다. 많은 사용 가능 MVC(100% 사용 가능한 공간, 마이그레이션된 VTV 없음)와 여러 ACS 및 MVC 매체 유형에 걸쳐 많은 사용 가능 공간이 있는 것으로 보입니다. 확보 가능한 MVC 수가 비교적 낮다는 것은 자동 공간 확보가 마이그레이션/회수 작업에 방해가 되지 않는다는 의미일 것입니다.

ACS 01, ECART 및 ZCART 매체를 제외하고 사용된 MVC는 사용 가능 MVC와 비교할 때 모두 정상인 것으로 보입니다. 이러한 MVC에 대해서는 추가 조사가 필요할 수 있습니다. 어떤 스토리지 클래스가 이러한 MVC를 나타내는지, 어떤 관리 클래스가 이러한 스토리지 클래스에 해당하는지 파악하고 관리 클래스별로 일부 VTV를 스크래치합니다.

Display MVCPool이 그림 4-2와 유사하게 표시된다면 어떻게 될까요?

그림 4-2 Display MVCPool의 출력 예 - ACS01의 문제

설명 그림 4-2 Display MVCPool의 출력 예 - ACS01의 문제

여기서 알 수 있듯이 ACS 01에서 상황이 더 악화되었습니다. 이제 어떻게 해야 할까요? 다음 방법을 가능한 순서대로 고려하십시오.
- 필요시 확보를 수행하여 공간을 확보합니다. 자세한 내용은 "요청식 MVC 공간 재생 수행"을 참조하십시오.
- "RTD 장치 유형 변경"에 설명된 대로 MVC를 추가합니다.
- 어떤 스토리지 클래스가 이러한 MVC를 나타내는지, 어떤 관리 클래스가 이러한 스토리지 클래스에 해당하는지 파악하고 관리 클래스별로 일부 VTV를 스크래치합니다.
  
  후속 작업으로 현재 정책을 검토하고 필요에 따라 조정합니다. 이러한 정책을 변경하여 사용 가능 MVC를 만들거나 MVC에서 공간을 확보할 수 있습니다.

전체적인 상태 파악(주간)

이 작업은 별로 복잡하지 않고 기본적으로 주마다 두 가지 기본적인 상태 도구(MVC 보고서 및 VTV 보고서) 실행으로 구성됩니다.

VTV 보고서 사용

주:

VTV 보고서는 다음 명령 중 하나를 사용하여 실행됩니다.

VTVRPT BASIC - EXPORT 명령을 사용하여 MVC로 마이그레이션된 모든 VTV 복사본을 보여줍니다.
VTVRPT COPIES - EXPORT 명령을 사용하여 MVC로 마이그레이션된 모든 VTV 복사본을 보여주고, 추가적으로 EEXPORT 명령을 사용하여 마이그레이션된 모든 VTV 복사본을 보여줍니다.

VTV 보고서부터 살펴보면 그림 4-3과 유사하게 표시됩니다.

그림 4-3 VTVRPT의 출력 예

설명 그림 4-3 VTVRPT의 출력 예

언뜻 보면 VTV 보고서는 시스템의 각 VTV 및 모든 VTV에 대해 알고자 하는 모든 것을 설명하는 수많은 데이터 라인이 있어 복잡하고 직관적이지 않게 보입니다.

VTV 보고서를 상황에 좀더 유용하게 만들 수 있는 방법은 없을까요? 우선 volser 목록, volser 범위 또는 개별 volser에 대해 VTVRPT 유틸리티를 실행할 수 있습니다. 조사하고자 하는 특정 VTV가 있다면 이러한 선택 옵션 중 하나를 사용합니다.

둘째, VTVRPT 유틸리티는 사용할 수 없는 VTV에 대한 보고서를 생성하는 OPTION(UNAVAIL) 매개변수도 제공하며, 그림 4-4와 유사하게 표시됩니다.

그림 4-4 VTVRPT의 출력 예(UNAVAIL 옵션)

설명 그림 4-4 VTVRPT의 출력 예(UNAVAIL 옵션)

상주하는 것으로 간주한 VTV에 액세스할 수 없는 작업(또는 VTCS) 보고서가 있었다면 분명히 OPTION(UNAVAIL)은 가장 적절한 옵션입니다.

또한 VTVRPT 유틸리티의 XML 출력에서 유연성을 얻을 수 있습니다. 선택한 보고서 및 유틸리티에 대해 구조화된 XML 또는 CSV(Comma Separated Variables) XML로 출력을 생성할 수 있습니다.

구조화된 XML과 CSV 출력의 차이는 무엇일까요? 다음을 고려하십시오.

구조화된 XML에는 각 명령이나 유틸리티에 대해 표시되는 모든 태그 및 구조가 포함됩니다(그런 다음 선택한 프로그래밍 언어를 사용하여 원하는 대로 처리할 수 있음).
CSV 출력에서는 원하는 태그(및 순서)만 선택할 수 있습니다. 각 출력 라인에는 콤마로 구분된 고정 필드 수가 포함되며, 나중에 사용자 정의 가능한 분석이나 보고서를 위해 스프레드시트 또는 보고서 작성기에 입력할 수 있습니다.

이제 조직의 필요에 따라 기본적인 VTV 보고서를 효과적으로 사용자 정의할 수 있는 두 가지 방법을 갖게 되었습니다. 이 항목에 대한 자세한 내용은 ELS Programming Reference를 참조하십시오.

마지막으로, LCM이 VTCS MVC 및 VTV 보고서를 포함하여 ELS/VTCS 기능에 해당하는 향상된 관리 및 보고 기능을 제공한다는 사실을 알고 있어야 합니다. 자세한 내용은 "LCM 제어문"을 참조하십시오.

MVC 보고서 사용

마지막으로 MVC 요약 보고서를 살펴보면 그림 4-5와 유사하게 표시됩니다.

그림 4-5 MVC 요약 보고서 예

설명 그림 4-5 MVC 요약 보고서 예

MVC 요약 보고서는 기존의 VTV 보고서와 많이 유사합니다. 찾고 있는 것을 알고 있다면 괜찮지만 그렇지 않다면 정보가 너무 많습니다.

MVC 상세 보고서에서 얻을 수 있는 추가 필드가 전체적인 상황을 파악하는 데 더 유용할 수 있습니다. 그림 4-6을 보십시오.

그림 4-6 MVC 요약 보고서 예(추가 필드)

설명 그림 4-6 MVC 요약 보고서 예(추가 필드)

여기에는 필요한 경우 몇 가지 진단 작업을 수행할 수 있는 MVC의 VTV에 대한 자세한 정보가 있습니다.

VTV 보고서와 마찬가지로 MVC 보고서에서도 다음 중 하나의 작업을 수행할 수 있습니다.

ELS Programming Reference에 설명된 대로 구조화된 XML 또는 CSV(Comma Separated Variables) XML로 출력을 생성합니다.
"LCM 제어문"에 설명된 대로 해당하는 LCM 보고서를 사용합니다.

요약

VTCS 대시보드 사용에 대한 모든 것을 설명했습니다. 명명된 MVC 풀을 사용한 경우 MVC 풀 보고서 실행 등과 같이 여러분이 수행할 수 있고 아마도 수행하게 될 몇몇 다른 작업도 있습니다. 그러나 이것은 ”필요에 따른” 관리 작업에 대한 정보입니다.

이 장에서 배워야 하는 가장 중요한 것은 가상 테이프 상태 확인(일간) 및 니어라인 테이프 상태 확인(일간)에 설명된 대로 일간 작업을 수행하고, "전체적인 상태 파악(주간)"에 설명된 대로 주간 작업을 수행하여 VTCS 시스템이 정상적으로 실행되도록 유지하는 것입니다.