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

application start

アプリケーションを開始します。

構文

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

パラメータ

<name>

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

<prop>=<val>

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

cpu - （オプション）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 が設定されている場合、開始は失敗します。

--norestart

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

--skipbuild

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

--force

検証を要求することなく、マウントされているボリュームを強制的にマウント解除します。

--cap_cpu

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

（以下の注を参照）

例

application start my-app

アプリケーションを開始します。

application start my-app --debug

デバッグ モードでアプリケーションを開始します。

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

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

application start my-app sched=crunch

最小限のリソースを割り当ててアプリケーションを開始します。

注：

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

  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 restart を使用します。