JavaScript is required to for searching.
탐색 링크 건너뛰기
인쇄 보기 종료
Oracle® ZFS Storage Appliance 관리 설명서, 릴리스 2013.1.3.0
Oracle Technology Network
라이브러리
PDF
인쇄 보기
피드백
search filter icon
search icon

문서 정보

Oracle ZFS Storage Appliance 정보

Oracle ZFS Storage Appliance 구성

서비스 작업

Oracle ZFS Storage Appliance 유지 관리

유지 관리 워크플로우 작업

워크플로우 이해

워크플로우 매개변수 이해

제한된 워크플로우 매개변수

선택적 워크플로우 매개변수

워크플로우 오류 처리

워크플로우 입력 검증

워크플로우 실행 감사 및 보고

워크플로우 버전 지정 이해

경보 조치에 워크플로우 사용

예약된 워크플로우 사용

예약된 워크플로우 사용

워크플로우 일정 코딩

지정된 드라이브 유형을 기반으로 워크시트 만들기

BUI를 사용하여 워크플로우 업로드

CLI를 사용하여 워크플로우 다운로드

CLI를 사용하여 워크플로우 나열

CLI를 사용하여 워크플로우 실행

공유 사용

Oracle ZFS Storage Appliance에 응용 프로그램 통합

경보 조치에 워크플로우 사용

워크플로우는 경보로 실행될 수도 있습니다. 워크플로우가 경보 조치로 실행될 수 있게 하려면 해당 alert 조치를 true로 설정해야 합니다.

경보 조치로 실행될 경우 워크플로우는 해당 워크플로우를 만든 사용자의 ID를 가집니다. 이 때문에 경보 조치로 실행될 수 있게 만들 모든 워크플로우에서 setidtrue로 설정해야 합니다. 경보 조치에는 다음과 같은 멤버가 포함된 단일 객체 매개변수가 있습니다.

표 4-8  경보 실행 컨텍스트의 필수 멤버
필수 멤버
유형
설명
class
문자열
경보의 클래스입니다.
code
문자열
경보의 코드입니다.
items
객체
경보를 설명하는 객체입니다.
timestamp
날짜
경보의 시간입니다.

매개변수 객체의 items 멤버에는 다음과 같은 멤버가 있습니다.

표 4-9  항목 멤버의 필수 멤버
필수 멤버
유형
설명
url
문자열
경보를 설명하는 웹 페이지의 URL입니다.
action
문자열
경보에 대한 응답으로 사용자가 수행해야 하는 작업입니다.
impact
문자열
경보가 발생하게 만든 이벤트의 영향입니다.
description
문자열
경보를 설명하며 사용자가 읽을 수 있는 문자열입니다.
severity
문자열
경보가 발생하게 만든 이벤트의 심각도입니다.

경보 조치로 실행되는 워크플로우에서는 audit 함수를 사용하여 감사 로그 항목을 생성할 수 있습니다. audit 함수를 통해 관련된 모든 디버깅 정보를 감사 로그에 생성해 넣는 것이 좋습니다. 예를 들어, 다음은 클러스터화된 상태에 있는 경우 페일오버를 실행하지만 재부트하기 위해 모든 오류를 감사하는 워크플로우입니다.

예 4-9  재부트 실패를 감사하는 워크플로우

예를 들어, 다음은 클러스터화된 상태에 있는 경우 페일오버를 실행하지만 재부트하기 위해 모든 오류를 감사하는 워크플로우입니다.

var workflow = {
       name: 'Failover',
       description: 'Fail the node over to its clustered peer',
       alert: true,
       setid: true,
       execute: function (params) {
               /*
                * To failover, we first confirm that clustering is configured
                * and that we are in the clustered state.  We then reboot,
                * which will force our peer to takeover.  Note that we're
                * being very conservative by only rebooting if in the
                * AKCS_CLUSTERED state:  there are other states in which it
                * may well be valid to failback (e.g., we are in AKCS_OWNER,
                * and our peer is AKCS_STRIPPED), but those states may also
                * indicate aberrent operation, and we therefore refuse to
                * failback.  (Even in an active/passive clustered config, a
                * FAILBACK should always be performed to transition the
                * cluster peers from OWNER/STRIPPED to CLUSTERED/CLUSTERED.)
                */
               var uuid = params.uuid;
               var clustered = 'AKCS_CLUSTERED';

               audit('attempting failover in response to alert ' + uuid);

               try {
                       run('configuration cluster');
               } catch (err) {
                       audit('could not get clustered state; aborting');
                       return;
               }

               if ((state = get('state')) != clustered) {
                       audit('state is ' + state + '; aborting');
                       return;
               }

               if ((state = get('peer_state')) != clustered) {
                       audit('peer state is ' + state + '; aborting');
                       return;
               }

               run('cd /');
               run('confirm maintenance system reboot');
       }
};