| StorageTek Tape Analytics 설치 및 구성 설명서 릴리스 2.0 E53329-01 |
|
 이전 |
 다음 |
이 장에서는 STA 1.0.x를 2.0으로 업그레이드하는 방법을 설명합니다. 이 프로세스는 STA 1.0.x에서 다른 1.0.x 버전으로 업그레이드하는 것과 다릅니다. 세 가지 이전 STA 1.0 릴리스 버전인 1.0.0.99, 1.0.1.133 및 1.0.2.24에서만 업그레이드할 수 있습니다. 업그레이드 후 STA는 새로운 버전의 스키마 및 분석 규칙에 따라 새 데이터를 처리합니다(과거 데이터는 다시 처리되지 않음).
|
주: 라이브러리 펌웨어와 STA를 동시에 업그레이드하는 경우 라이브러리 엔진 ID 및 SNMP 구성을 업데이트해야 할 수 있습니다. STA 관리 설명서의 ”라이브러리 SNMP 연결 관리”를 참조하십시오. |
STA 2.0 요구 사항 검토: STA 요구 사항 설명서를 참조하십시오.
데이터베이스 백업을 별도의 서버로 이동: STA 백업 서비스에서 만들어진 데이터베이스 백업은 업그레이드 후 더 이상 유효하지 않습니다.
STA 1.0.x 설정 기록: WebLogic 및 MySQL 자격 증명, 포트 번호, SNMP 클라이언트 속성 및 "STA-"로 시작되는 공용 템플리트는 보존되지 않습니다. "업그레이드 워크시트"를 사용하여 STA 1.0.x 설정을 기록하십시오. 동일한 계정 사용자 이름각주 1 및 SNMP 클라이언트 속성을 STA 2.0에서 사용하려면 작업 1에서 이 정보를 가져오기 위한 지침을 제공합니다. "STA-"로 시작되는 저장된 공용 템플리트를 보존하려면 업그레이드 전에 새 이름으로 저장하십시오각주 2 .
STA 1.0.x가 제대로 구성되고 작동하는지 확인: Monitored Libraries 테이블에서 각 라이브러리에 STA 서버와 최근 성공한 통신이 있는지 확인하십시오.
소프트웨어 다운로드: STA 2.0은 2개의 대용량 미디어 팩 ZIP 파일로 구성되어 있습니다. 처음 몇 가지 업그레이드 작업을 완료하는 동안 지금 파일 다운로드를 시작하는 것이 좋습니다("STA 다운로드" 참조).
표 9-1 STA 2.0 설치에 필요한 정보
| 필요한 정보 | STA 1.0.x 값 | STA 2.0 값각주 1 |
|---|---|---|
|
WebLogic 관리 콘솔 로그인 사용자 이름 |
||
|
WebLogic 관리 콘솔 로그인 암호 |
||
|
STA GUI 로그인 사용자 이름 |
||
|
STA GUI 로그인 암호 |
||
|
STA 데이터베이스 루트 계정 암호각주 2 |
||
|
STA 데이터베이스 응용 프로그램 계정 사용자 이름 |
||
|
STA 데이터베이스 응용 프로그램 계정 암호 |
||
|
STA 데이터베이스 보고서 계정 사용자 이름 |
||
|
STA 데이터베이스 보고서 계정 암호 |
||
|
STA 데이터베이스 DBA 계정 사용자 이름 |
||
|
STA 데이터베이스 DBA 계정 암호각주 2 |
||
|
WebLogic 관리 콘솔 로그인 포트, HTTP(기본값 7001) |
||
|
WebLogic 관리 콘솔 로그인 포트, HTTPS(기본값 7002) |
||
|
STA GUI 로그인/staUi 관리 서버 포트, HTTP(기본값 7021) |
||
|
STA GUI 로그인/staUi 관리 서버 포트, HTTPS(기본값 7022) |
||
|
staEngine 관리 서버, HTTP(기본값 = 7023) |
해당 없음 |
|
|
staEngine 관리 서버, HTTPS(기본값 = 7024) |
해당 없음 |
|
|
staAdapter 관리 서버, HTTP(기본값 = 7025) |
해당 없음 |
|
|
staAdapter 관리 서버, HTTPS(기본값 = 7026) |
해당 없음 |
|
|
회사 도메인 이름(예: us.oracle.com) |
각주 1 STA 2.0에 대해 기존 STA 1.0.x 값을 사용하거나 새로운 값을 선택할 수 있습니다.
각주 2 데이터베이스 루트 또는 DBA 계정 암호는 작업 2, "STA 1.0.x 데이터베이스 덤프"에 필요합니다.
표 9-2 STA 2.0 사후 설치 구성에 필요한 정보각주 1
| 필요한 정보 | STA 1.0.x 값 | STA 2.0 값 |
|---|---|---|
|
SNMP v3 사용자 이름 |
||
|
SNMP v3 권한 부여 암호(Auth) |
||
|
SNMP v3 프라이버시 암호화 암호(Privacy) |
||
|
사용자 커뮤니티 |
||
|
트랩 커뮤니티 |
||
|
추가 WebLogic 사용자 이름 및 암호 |
각주 1 SNMP 값은 라이브러리에서 지정된 값과 일치해야 합니다.
단일 서버 방식(도표9-1): 모든 작업을 번호 순서대로 완료합니다.
두 대의 서버 방식(도표9-2): 작업이 번호 순서대로 수행되지 않습니다. 작업 7은 생략하고 다음 순서대로 작업을 완료해야 합니다.
|
주의: Linux 관리자 및 STA 관리자만 업그레이드를 수행해야 합니다. 지정된 순서대로 정확하게 단계를 따르지 않을 경우 데이터 손실이 발생할 수 있습니다. |
이 절차를 사용하여 STA 1.0.x WebLogic 사용자 이름, MySQL 데이터베이스 사용자 이름 및 SNMP 클라이언트 속성을 가져오십시오. 자세한 내용은 "업그레이드하기 전에"를 참조하십시오.
|
주: WebLogic, MySQL 및 SNMP 사용자 이름과 연관된 암호는 되찾을 수 없습니다. |
WebLogic 사용자 목록을 가져오려면 다음과 같이 합니다.
STA 설치 중 선택한 HTTP(기본값 7001) 또는 HTTPS(기본값 7002) 포트 번호를 사용하여 WebLogic 콘솔 로그인 화면으로 이동합니다.
http(s)://yourHostName:PortNumber/console/
WebLogic 관리 콘솔 사용자 이름과 암호를 사용하여 로그인합니다.
Domain Structure(화면의 왼쪽)에서 Security Realms를 누릅니다.
Realms에서 myrealm을 선택합니다(확인란이 아닌 이름 자체를 선택합니다).
Users and Groups 탭을 선택합니다.
STA 사용자 목록이 Users 테이블에 나타납니다.
MySQL 데이터베이스 사용자 목록을 가져오려면 다음과 같이 합니다.
터미널 세션에서 STA 1.0.x 서버에 로그인합니다.
다음 명령을 실행하고 프롬프트가 표시되면 MySQL 루트 사용자 암호를 입력합니다.
# mysql -uroot -p -e "select distinct(user) from user order by user ;" mysql Enter password: root-password
표시된 STA 데이터베이스 사용자 이름 목록을 기록합니다. 예:
+--------+ | user | +--------+ | root | | staapp | | stadba | | starpt | +--------+
SNMP 클라이언트 속성을 보려면 다음과 같이 합니다.
HTTP(기본값 7021) 또는 HTTPS(기본값 7022) 포트 번호를 사용하여 STA GUI 로그인 화면으로 이동합니다. "STA"는 대문자여야 합니다.
http(s)://yourHostName:PortNumber/STA/
STA GUI 로그인 사용자 이름과 암호를 사용하여 로그인합니다.
탐색 메뉴에서 Settings > SNMP Connections를 선택합니다.
SNMP Username, User Community 문자열 및 Trap Community 문자열이 Client Attributes 테이블에 표시됩니다.
STA 1.0.x 서버에서 터미널 세션을 엽니다.
다음 명령을 실행하여 모든 STA 서비스를 중지합니다.
# STA stop
다음 명령을 실행하여 MySQL 서비스를 시작합니다.
# service mysql start
다음 명령을 실행하여 데이터베이스를 단일 파일로 덤프합니다.
# /usr/bin/mysqldump -uroot -p --opt --routines --events --flush-logs --single-transaction --complete-insert --comments --dump-date --add-drop-database --databases stadb -v > /desired_path_for_dumpfile/dump_file_name.sql Enter password: mysql_root_password
|
주: -v(선택적, 상세 정보 표시 출력용)는 명령 진행 상황을 표시합니다. 하지만 대용량 데이터베이스의 경우 덤프 프로세스 속도가 매우 느려질 수 있습니다. |
예 9-1 STA 1.0.x 데이터베이스 덤프
이 예에서 STA 1.0.x 데이터베이스는 STA 서버의 root 폴더에 파일 이름 20130711_dump.sql로 덤프되었습니다.
# /usr/bin/mysqldump -uroot -p --opt --routines --events --flush-logs --single-transaction --complete-insert --comments --dump-date --add-drop-database --databases stadb -v > /root/20130711_dump.sql
Enter password: mysql_root_password
...
-- Retrieving view structure for table v_library_complex_io...
...
-- Retrieving view structure for table v_library_summary_averages...
-- It's base table, skipped
...
-- Retrieving table structure for table v_mdv_status_codes...-- It's a view, create dummy table for view
...
-- Disconnecting from localhost...
덤프 파일 크기를 약 50%로 줄이기 위해 파일을 gzip으로 압축합니다.
# cd /path_to_dump_file/ # gzip dump_file_name.sql
이 작업에서 압축된 STA 1.0.x 데이터베이스 덤프 파일은 오프 플랫폼 백업 서버(단일 서버 방식) 또는 새로운 STA 2.0 서버(두 대의 서버 방식)로 전송됩니다.
|
주의: 단일 서버 업그레이드 방식을 따르는 경우 STA 데이터베이스를 다른 서버에 백업해야 합니다. 작업 4의 Linux 6.x 설치로 인해 서버의 모든 데이터가 삭제되므로 데이터베이스를 기존 STA 서버의 파일 시스템에 백업하지 마십시오. |
파일을 백업 서버로 전송하기 전에 체크섬을 수행합니다.
# cksum dump_file_name.sql.gz
출력에는 체크섬 값과 바이트 수가 포함됩니다. 체크섬 값을 기록하십시오. 이 값은 파일을 백업 서버로 전송한 후 파일 무결성을 확인하는 데 사용됩니다.
SCP와 같은 전송 유틸리티를 사용하여 파일을 대상 서버로 전송합니다. -p 옵션은 시간 기록 값을 유지합니다.
# scp -p dump_file_name.sql.gz target_host:/path/
대상 서버에서 전송된 파일의 체크섬을 수행합니다. 체크섬 값이 일치하는지 확인합니다.
# cd /path_to_dump_file/ # cksum dump_file_name.sql.gz
|
주의: 단일 서버 업그레이드 방식을 따르는 경우 STA 데이터베이스가 다른 서버에 성공적으로 백업되었는지 확인하십시오. 이 작업에서 STA 서버의 모든 데이터는 삭제됩니다. |
Linux 6.x는 Linux 5.x의 주요 업그레이드로 간주되기 때문에 in-place 업그레이드는 Linux에서 지원되지 않습니다(기존 Linux 5.x 파일 시스템을 보존하면서 OS를 업그레이드할 수 없습니다). Linux 6.x는 STA 1.0.x 서버에 새로 설치됩니다.
Linux 6.x를 설치 및 구성하려면 1장, "Linux 설치"를 참조하십시오.
2장, "STA 설치"에 따라 STA 2.0을 설치합니다.
나머지 업그레이드 작업을 수행하기 전에 STA 사용자 인터페이스에 로그인하여 STA가 제대로 작동하는지 확인합니다("STA 사용자 인터페이스에 로그인" 참조).
STA 서버에서 터미널 세션을 엽니다.
다음 명령을 실행하여 모든 STA 2.0 서비스를 중지합니다.
# STA stop all
(선택 사항) STA 1.0.x 서버가 SNMP v2c를 사용하여 라이브러리와 통신하도록 구성된 경우 STA 2.0 서버에서 v2c 모드를 사용으로 설정해야 합니다. 부록B, "STA에 대해 SNMP v2c 모드 사용"의 절차를 따르지만 STA를 중지하고 다시 시작하기 위한 마지막 단계는 생략하십시오. 이미 STA를 중지했고 업그레이드 프로세스의 나중에 다시 시작할 것이므로 이 작업은 필요하지 않습니다.
업그레이드를 실패할 경우 백업 덤프 파일을 사용하여 데이터 없이 새로 설치된 것처럼 STA가 실행되도록 구성할 수 있는 상태로 STA를 복구해야 합니다.
다음 명령을 실행하여 MySQL 서비스를 시작합니다.
# STA start mysql
다음 명령을 실행하여 백업 파일을 만듭니다.
# /usr/bin/mysqldump -uroot -p --opt --routines --events --flush-logs --single-transaction --complete-insert --comments --dump-date --add-drop-database --databases stadb -v > /dbbackup/STA_FRESH_INSTALL_BACKUP.sql Enter password: mysql_root_password
출력은 다음과 유사합니다.
... -- Retrieving view structure for table v_mdv_request_states... -- Retrieving view structure for table version_info... ... -- Disconnecting from localhost...
|
주: "Can’t connect to local MySQL server"가 표시되는 경우 MySQL 서버가 실행되고 있지 않는 것입니다. MySQL을 시작했는지 확인하십시오(1단계). |
단일 서버 방식만 해당: SCP를 사용하여 STA 1.0.x 데이터베이스의 백업된 복사본을 STA 2.0 서버로 전송할 수 있습니다. -p 옵션은 시간 기록 값을 유지합니다.
다음 명령을 실행합니다.
# scp -p backup_host:/path_to_dump_file/dump_file_name.sql.gz /local_path
전송된 파일의 체크섬을 수행합니다. 체크섬 값이 작업 2에서 기록한 값과 일치하는지 확인합니다.
# cd /path_to_dump_file/ # cksum dump_file_name.sql.gz
이 작업에서는 압축된 STA 1.0.x 데이터베이스의 압축을 풀고 STA 서버에 복구합니다.
백업 파일의 압축을 풉니다.
# gunzip dump_file_name.sql.gz
(선택 사항) 다음 단계를 수행하여 더 이상 사용되지 않는 데이터의 STA 데이터베이스를 비웁니다(예: 이미 처리된 SNMP 레코드 및 빈 분석 레코드). 이 작업은 권장되며, 크기가 1GB가 넘는 데이터베이스의 경우 데이터베이스 크기 및 로드 시간이 크게 줄어듭니다. 이 작업의 나머지 단계에서는 비우기가 수행되었다고 간주합니다. purgerecs 명령 작업의 영구 레코드는 STA 데이터베이스에 저장됩니다.
|
주: 또한 STA 2.0에서는 데이터베이스 비우기가 런타임에 자동으로 발생합니다. 정기적으로 MySQL Event Scheduler는 데이터베이스에서 처리된 SNMP 레코드를 비워 데이터베이스 증가를 최소화합니다. |
STA 업데이트 디렉토리로 변경합니다.
# cd /Oracle/StorageTek_Tape_Analytics/db/updates
다음 명령을 실행합니다.
# ./purgerecs /path_to_dump_file/dump_file_name.sql /path_to_dump_file/purged_dump_file_name.sql
|
주: purgerecs 명령에 대한 도움말을 보려면 다음을 입력하십시오.
# ./purgerecs -h
|
예 9-5 STA 1.0.x 데이터베이스에서 더 이상 사용되지 않는 데이터 비우기
이 예에서 /root의 압축이 풀린 MySQL 덤프 파일 20130711_dump.sql은 purgerecs 유틸리티를 사용하여 비워지고, 출력은 /root의 20130711_dump_purged.sql이라는 새로운 파일로 지정되었습니다. 진행 상태 점은 200개의 레코드가 처리될 때마다 나타납니다.
# cd /Oracle/StorageTek_Tape_Analytics/db/updates
# ./purgerecs /root/20130711_dump.sql /root/20130711_dump_purged.sql
................................................
STA v1.0.2, Schema 33.02
Processed 11,689 lines from '20130711_dump.sql':
------------------------------------------------
snmp_storage_cells........1,614,255
snmp_media................110,205
...
media_summaries...........254
transform_logs............0
================================================
Records Processed:........13,143,283
Records Purged:...........2,857,623
Records Remaining:........10,285,660
Elapsed Time:.............00:00:11
(선택 사항) 다음 명령을 사용하여 데이터베이스 파일 크기를 확인하고 로드 프로세스 시간을 예측합니다. 로드 프로세스는 압축이 풀린 데이터베이스 스냅샷 크기에 대해 실행하는 데 기가바이트당 최대 5분이 소요됩니다.
# ls -s -h purged_dump_file_name.sql
STA 1.0.x 데이터베이스를 로드합니다.
# mysql -uroot -p -e "SET SESSION SQL_LOG_BIN=0; SOURCE /path_to_dump_file/dump_file_name;" Password: mysql_root_password
명령을 성공할 경우 프로세스가 완료되면 명령 프롬프트로 돌아옵니다. -v(상세 정보 표시) 옵션을 지정하지 않을 경우(권장되지 않음) 프로세스가 실행될 때 명령 출력이 보이지 않습니다.
명령 설명:
-p: STA 2.0 설치 중 설정된 MySQL 루트 암호를 물어봅니다.
-v: 상세 정보 표시 출력(선택 사항)입니다. 로드 프로세스 속도가 매우 느려질 수 있습니다.
-e: 다음 따옴표로 묶인 명령문을 실행합니다.
SET SESSION SQL_LOG_BIN=0;: 불필요한 바이너리 로깅을 해제하여 로드 속도를 높입니다.
SOURCE /path_to_dump_file/: 덤프 파일을 DB에 로드합니다.
프로세스는 업그레이드하는 STA 1.0.x 버전에 따라 압축이 풀린 데이터베이스 스냅샷 크기에 대해 실행하는 데 기가바이트당 약 2분이 소요됩니다.
다음 명령을 실행하여 STA 1.0.x 데이터베이스를 새로운 STA 2.0 스키마로 업그레이드합니다.
# cd /Oracle/StorageTek_Tape_Analytics/db/updates # ./upgradedb.sh DB Root Password: mysql_root_password
|
주: 보안상의 이유로 암호는 표시되지 않습니다.upgradedb.sh 명령에 대한 도움말을 보려면 다음을 입력하십시오.
# ./upgradedb.sh -h
|
예제 출력:
+-------------------------------------------------------------+ | STA DATABASE UPGRADE | | Upgrading DB schema from 49.00r0 to 50.00r0 | | Started: 2014-01-14 01:21:47 | +-------------------------------------------------------------+ STA database contains approximately 4,301 records. installed version 49.00 is a valid upgrade candidate, proceeding... ...allow approximately two minutes per 1GB of file size...
프로세스가 완료되면 다음과 유사한 배너가 나타납니다.
+-------------------------------------------------------------+ | Started.................2014-01-14 01:21:47 | | Finished................2014-01-14 01:21:54 | | Elapsed Time............00:00:07 | | Starting Version........49.00r0 | | Final Schema Version....50.00r0 | | Schema Release Date.....2014-01-08 15:16:17 | | Records (approximate)...4,282 | +-------------------------------------------------------------+
다음 명령을 실행하여 모든 STA 서비스를 시작합니다.
# STA start all
(선택 사항) 업그레이드를 성공할 경우 STA_FRESH_INSTALL_BACKUP.sql 파일을 삭제하여 /dbbackup 볼륨의 디스크 공간을 확보합니다.
업그레이드 방식에 따라 진행합니다.
단일 서버 방식: 업그레이드 프로세스 중 STA 서버의 IP 주소를 변경한 경우 각 라이브러리의 트랩 수신자 목록을 다시 추가하여 STA 서버의 새로운 IP 주소를 반영하십시오. 트랩 수신자를 다시 추가하려면 STA 관리 설명서의 "라이브러리 SNMP 관리 작업"을 참조하십시오.
두 대의 서버 방식:STA 2.0 서버를 새로운 트랩 수신자로 각 라이브러리의 SNMP 구성에 추가하십시오. "SNMP v3 트랩 수신자 만들기" 또는 "SNMP v2c 트랩 수신자 만들기"를 참조하십시오.
|
주: STA 2.0은 두 가지 새로운 트랩 레벨인 13(테스트 트랩) 및 14(상태 트랩)를 지원합니다. 이러한 레벨이 각 모니터되는 라이브러리의 트랩 수신자 목록에서 이전에 지정되지 않은 경우 레벨 13 및 14가 포함된 트랩 수신자 목록도 다시 추가해야 합니다. |
"STA 사용자 인터페이스에 로그인"에 설명된 대로 STA에 로그인합니다.
"STA에 대한 SNMP 클라이언트 설정 구성"에 설명된 대로 SNMP 클라이언트 속성을 다시 입력합니다.
각 모니터되는 라이브러리에 대한 연결 세부 정보를 업데이트합니다.
탐색 메뉴에서 Setup & Administration > Configuration > SNMP Connections를 선택합니다.
Monitored Libraries 섹션에서 라이브러리 이름을 선택한 다음 Edit 버튼을 누릅니다.
STA IP Address 드롭다운에서 STA 2.0 서버의 IP 주소를 선택합니다.
Save를 누릅니다.
목록의 각 모니터되는 라이브러리에 대해 이러한 단계를 반복합니다.
올바른 통신을 확인하기 위해, "라이브러리에 대한 SNMP 연결 테스트"에 설명된 대로 각 구성된 라이브러리에 대한 연결을 테스트합니다.
연결을 테스트하기 전에 Last Successful Connection 및 Last Connection Attempt 시간 기록을 메모해 두십시오. 테스트를 수행한 후 시간 기록을 비교하여 테스트에서 현재 정보를 제공하는지 확인할 수 있습니다.
"라이브러리에서 최신 구성 데이터 가져오기"에 설명된 대로 각 라이브러리에서 최신 데이터를 가져옵니다.
"사용자 및 전자 메일 구성"의 절차에 따라 STA 사용자를 변경하거나 만들고 전자 메일 등록 정보를 구성(및 테스트)합니다.
추가 STA 사용자(기본 관리 콘솔 로그인 및 STA GUI 로그인 사용자 이외의 사용자)를 작업 1에서 기록한 경우 지금 이러한 동일 사용자를 만들고 적절히 역할을 지정할 수 있습니다.
|
주: 대부분의 전자 메일 통지 설정은 STA를 업그레이드할 때 보존되지만 SMTP 통신을 다시 사용으로 설정하고 전자 메일 계정 암호를 다시 입력해야 합니다. |
다음 장에 따라 STA의 나머지 구성 요소를 구성(또는 재구성)합니다.
두 대의 서버 방식을 따른 경우 지금 STA 1.0.x 서버를 구성 해제할 수 있습니다.
선택적으로 트랩 수신자로서 STA 1.0.x 서버를 각 라이브러리의 SNMP 구성에서 제거할 수 있습니다. 트랩 수신자를 삭제하려면 STA 관리 설명서의 "라이브러리 SNMP 관리 작업"을 참조하십시오.
각주 범례
각주 1: STA 2.0에서 추가 응용 프로그램 사용자는 WebLogic이 아닌 STA UI 내에서 만들어집니다.