参照情報 › コマンド ライン シェル リファレンス ガイド › シェル コマンド › アプリケーション制御 › application restart

application restart

アプリケーションを再起動します。

構文

application restart <name> ( <prop>=<val> )* [ store=<store>]
                            [ --debug ] [ --clean ] [ --norestart ]
                            [ --skipbuild ] [ --cap_cpu  ] [ --force ]

パラメータ

<name>

アプリケーションの名前。

<prop>=<val>

スケジュールのパラメータ。 以下のパラメータを指定できます。

cpu - （オプション）CPU 割り当て（val[%]）

mem - （オプション）メモリ割り当て（val[M[B]|G[B]]）。 単位が指定されない場合、メモリの単位は MB です。

bw - （オプション）帯域幅の割り当て（val[M[b]|G[b]]）。 単位が指定されない場合、帯域幅の単位は Mbps です。

sched - スケジュール ターゲットを指定する文字列（下記を参照）

servers - アプリケーションが開始されるサーバの数。

<store>

インスタンス ボリュームが作成されるボリューム ストアを指定します。 以下のいずれかの値に設定できます。

local - ボリュームをローカル サーバ ストレージに格納します

san - ボリュームを SAN に格納します

--debug

アプリケーションをデバッグ モードで再起動します。 このオプションが指定されていて、アプリケーションにフィールド エンジニアリング コード 16 が設定されている場合、再起動は失敗します。

--clean

再起動の前にアプリケーションをクリーンアップします。

--norestart

グリッド障害時にアプリケーションを再起動しません。

--skipbuild

再起動の前にアプリケーションをビルドしません。

--force

検証を要求することなく、現在使用されているボリュームを強制的に解放します。 これは、現在実行されていないアプリケーションを再起動するときに役立ちます。 CA AppLogic 2.8.8 以降でサポートされています。

--cap_cpu

アプリケーションのすべてのコンポーネントに対して CPU のキャッピングを有効にします。

（以下の注を参照）

例

application restart my-app

アプリケーションを再起動します。

application restart my-app --debug

アプリケーションをデバッグ モードで再起動します

application restart my-app cpu=2 mem=1024M

CPU およびメモリ割り当てを変更してアプリケーションを再起動します

application restart my-app sched=crunch

最小限のリソースを割り当ててアプリケーションを再起動します

注：

• このコマンドはアプリケーションの stop および start コマンドを組み合わせたものです。

  --clean および --skipbuild オプションは同時に指定できません。

  以下のスケジュール ターゲットがサポートされています。

  sched="percentile=(resource percentile)"

  sched=crunch - すべてのコンポーネントに最小リソースを割り当てます。「percentile=0」と同じです。

  sched=expand - すべてのコンポーネントに最大リソースを割り当てます。「percentile=100」と同じです。

  sched="mode=(scheduling mode)" - 有効な値は以下のいずれかです。

  1. pack servers。サーバ上のアプライアンスに利用可能な最小限のリソースを割り当ててスケジュールします。
  2. round robin with random start。最初のアプライアンスをランダムにサーバにスケジュールし、残りのアプライアンスについてはラウンド ロビンを使用してほかのサーバに割り当てます。
  3. round robin。最初のアプライアンスを最初のサーバ上でスケジュールし、残りのアプライアンスについてはラウンド ロビンを使用してほかのサーバに割り当てます。
• pack server スケジュール モードを使用すると、割り当てられた役割と利用可能な最小限のリソースに基づいて優先順位に従ってサーバが選択されます。 CA AppLogic は、常に役割が「なし」のサーバを最初に、「プライマリ」のサーバを 2 番目に、「セカンダリ」を最後にそれぞれ選択します。これらのサーバの利用可能なリソースは考慮されません（「なし」のサーバがすべて使用されるまでプライマリ サーバは使用されず、すべての「なし」および「プライマリ」のサーバが使用されるまでセカンダリサーバは使用されません）。
• --cap_cpu オプションを使用してアプリケーションが再起動されると、アプリケーションの各アプライアンスはそれぞれに割り当てられた以上の CPU を使用できません。たとえば、アプライアンスに CPU の 30% が割り当てられている場合、CPU に利用可能なサイクルがあっても、30% を超える CPU を使用することはできません。 対照的に、CPU をキャッピングしていない場合、アプライアンスはサーバで利用可能な CPU をすべて使用できます。
• アプリケーションが --debug を使用して再起動され、アプリケーションが開始に失敗する場合は、CA AppLogic はアプリケーションをクリーンアップしない（つまり、正常に開始したアプライアンスを停止する）ため、ユーザが開始失敗の理由を判断できます ユーザがその問題を解決できる場合、「app continue」コマンドを使用して、アプリケーションの開始を続行できます。
• --debug が指定されていて、アプリケーションにフィールド エンジニアリング コード 16 が設定されている場合、アプリケーションの再起動は失敗します。
• アプリケーションを再起動すると、コンポーネントのフラッピング カウンタ（CA AppLogic によって管理）がリセットされます。 コンポーネントのフラッピング カウンタは、過去 24 時間内にコンポーネントが失敗した回数です（各コンポーネントには固有のフラッピング カウンタがあります）。 コンポーネントが 24 時間に 3 回失敗すると、コンポーネントは CA AppLogic によって再起動されません。 コンポーネントのフラッピング カウンタをリセットするには、comp start/restart または app start を使用します。