JavaScript is required to for searching.
ナビゲーションリンクをスキップ
印刷ビューの終了
Oracle® ZFS Storage Appliance 管理ガイド、Release 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 に設定されている必要があります。警告アクションには、次のメンバーを持つ 1 つのオブジェクトパラメータがあります。

表 4-8  警告の実行コンテキストの必須メンバー
必須メンバー
タイプ
説明
class
文字列
警告のクラス。
code
文字列
警告のコード。
items
オブジェクト
警告を記述したオブジェクト。
timestamp
日付
警告の時間。

parameters オブジェクトの items メンバーには、次のメンバーがあります。

表 4-9  items メンバーの必須メンバー
必須メンバー
タイプ
説明
url
文字列
警告を記述した Web ページの 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');
       }
};