AppLogic は、Boundary プロパティ、出力、および入力を読み取った後、appl_start スクリプトを使用して設定を生成し、/config および [config extention] を設定します。 異なるプレースホルダ ボリュームにデータを配置し、読み取り専用のインスタンス化可能なボリュームに /os と /app を配置することにより、コードから設定とデータを分離する必要があります。
プレースホルダ ボリュームはボリュームを添付できる場所です。 これらのボリュームは、アプライアンス クラスではなく、アプリケーションに属するファイルやデータベースなど、アプライアンスに固有のコンテンツに使用されます。 プレースホルダ ボリュームは、ファイルやデータベースなどの永続的な状態用であり、Web サーバの html ファイルなどの固定コンテンツを提供します。
プレースホルダ ボリュームとは異なり、インスタンス化可能なボリュームはアプライアンス クラスに属し、カタログ クラスでコピーおよびマイグレートされます。
重要 インスタンス化可能なボリュームはアプライアンスの開始時に失われ、コピー上に保持されず、アプライアンスが存在するアプリケーションからマイグレートされない可能性があります。 その例外はシングルトンです。 インスタンス化可能なボリュームは、シングルトンのアプライアンスに対して常に保持されます。
以下の手順に従います。
［ボリューム］タブが表示されます。
［ボリュームの作成］ダイアログ ボックスが表示されます。
ボリュームのタイプ。 例： プレースホルダ
アプリケーションの一意の名前。 例： データ
メガバイトまたはギガバイトでのボリュームのサイズ。 例： 100M
ボリュームにインストールされているファイルシステム。 例： ext3
［次へ］をクリックしてから、［閉じる ］をクリックします。
［ボリューム］タブが表示されます。
インフラストラクチャ エディタが表示されます。
vol manage appliancename.volumename --rw
mkdir content
インフラストラクチャ エディタが表示されます。
前に、アプライアンス境界を定義しました。 今度は、境界を内部に結び付けて、アプライアンスの初期化とスタートアップを設定する必要があります。 これにより、アプライアンスは、それ自体の仮想化環境で実行し、それ自体のオペレーティング システム、アプリケーション サービス、および他の必要なソフトウェアを起動できるようになります。
アプライアンスの内部は以下のものから構成されます。
境界に内部を結び付ける最も重要な部分は、アプライアンス スタートアップ中に実行されます。
アプライアンス ブート プロセスの間に、APK には 2 つの機能があります。
たとえば、設定プロセスの初期に APK は
applogic_init_config ファイルを使用すると、APK によって自動設定される OS 設定の部分を変更できます。 詳細については、Linux アプライアンスまたは Windows アプライアンスのアプライアンス動作のカスタマイズを参照してください。
アプライアンス インスタンス記述子には、すべてのネットワーク インターフェースやディスク ボリュームのデバイス名など、OS 固有の情報が含まれます。 この特定のアプライアンス クラスをアプリケーションに追加するときは、設定可能なプロパティおよび他のアプライアンスや外界への接続に対する特定の値でそのクラスのインスタンスを作成します。 起動時に、この特定の設定全体が仮想アプライアンスに渡されます。
アプライアンス起動スクリプト
初期の設定が完了し、重要な OS が開始した後、アプライアンスの起動スクリプトが開始します。 このオプションのスクリプトを使用すると、アプライアンスのソフトウェア製品の特定の機能に適合するように、アプライアンス境界プロパティを調整できます。
APK は、1 つの設定ファイルと 1 つのフックをスクリプトに提供します。 ファイルの場所は OS に固有です。 たとえば、Linux や BSD のような Posix スタイルのオペレーティング システムの場合はファイルは /etc/sysconfig/ にあり、Windows オペレーティング システムの場合は ¥aookiguc¥config¥ にあります。
次のファイルがあります。
APK が自動的に実行する OS セットアップの部分を定義する設定オプションを提供し、APK がプロパティ設定を適用する設定ファイルのリストを指定します。 このファイルの存在はオプションです。 APK にはファイルで指定できるすべての設定に対するデフォルトがあります。
APK が AppLogic にスタートアップ ステータスをレポートする直前に実行される遅延セットアップのフックを提供します。 このフックを使用すると、アプライアンス固有の設定および起動サービスを実行できます。 フックは、リターン ステータスを返し、失敗した場合は標準エラー出力ストリームに 1 行のメッセージを出力することが期待されます。 このメッセージはグリッド ダッシュボードに表示されます。
さらに、アプライアンスは、OS で提供されるスタートアップ機能を使用できます（Linux の sys5 initi や、Windows のサービス コントロール マネージャなど）。
アプライアンス固有のスタートアップ確認スクリプト
アプライアンス固有のスタートアップが完了した後、APK は必要に応じてアプライアンスに固有のスタートアップ確認スクリプトを実行します。 スクリプトは、アプライアンスが開始したことを確認し、コントローラに成功または失敗のメッセージを返します。 スクリプトがエラーを返すと、アプライアンス スタートアップ確認は停止し、失敗メッセージを送信します。 スクリプトが返されないか、スクリプトがエラーなしで戻る場合、アプライアンス スタートアップ確認は開始成功を送信します。
アプライアンス インスタンス記述子
アプライアンス インスタンス記述子には、すべてのネットワーク インターフェースやディスク ボリュームのデバイス名など、OS 固有の情報が含まれます。 この特定のアプライアンス クラスをアプリケーションに追加するときは、設定可能なプロパティおよび他のアプライアンスや外界への接続に対する特定の値でそのクラスのインスタンスを作成します。 起動時に、この特定の設定全体が仮想アプライアンスに渡されます。
ユーザがアプリケーションを設定して開始するとき、対応するインスタンス記述子には次のような情報が含まれます。
property weight: integer, value=37 # appliance was configured with specific value volume data: dev=/dev/sdc, mount=/opt # configured, appears as /dev/sdc # to the operating system volume cache: disconnected # optional, app designer chose not to configure it
端子は、同じアプリケーション内のアプライアンスとの対話のような、アプライアンス間の接続にのみ使用される専用のネットワーク インターフェースです。 端子はホスト名と考えることができます。
IP アドレスが含まれる場合、APK は自動的に端子ネットワークを設定します。 アプライアンスは IP アドレスを変更できません。 APK は、既存のソフトウェアと統合しやすいように、端子をホスト名のように表します。 端子の設定は、アプライアンス記述子ファイルおよび APK ユーティリティで確認できます。 ユーザが IP アドレスを指定すると、ユーティリティは端末名を表示します。
端子の種類は以下のとおりです。
IN はホスト名です。 ホスト名 IN の解決を試みると、自分の端子の IP アドレスを取得します。 これは、サーバがリスンするインターフェースを設定する場合に役立ちます。 たとえば、HTP Load Balancer （HALB）は、IN 入力端子でディスパッチ要求を受け付け、CTL 端子でコントロール要求を受け付けます。 これは HALB が動作するただ一つの方法です。
出力は最も頻繁に使用される端子です。 出力端子の名前は、接続されている他のアプライアンスに通知する接続先のホスト名としてアプライアンス内で使用できます。
APK は、IP アドレスの出力に接続されている入力の IP アドレスに名前をマップします。 たとえば、web6 はデータベースに接続するためにデータベース ホストを参照できます。 mysql –h –db を使用して、web6 への mysql データベースに接続できます。
ホスト名として fs 端子を使用すると、fs 端子は NAS アプライアンス内の nfs サーバの IP アドレスを解決します。 find コマンド - fs l-share /mnt をマウントします
注： アプライアンス境界では、端子名へのエイリアスになるホスト名を設定できます。 これは、ホスト名がソフトウェア パッケージ内にハードコードされているときに役立ちます。 APK は接続されたアプライアンスの IP アドレスにエイリアスをマップします。
単一のホスト名またはサービスに接続するために使用される通常の出力端子とは異なり、ゲートウェイ出力端子は、通常はネット ゲートウェイ アプライアンスを介して、複数のホストに接続するために使用されます。
アプライアンスの境界にゲートウェイ端子が設定されている場合、APK は自動的にアプライアンスおよびその DNS サーバに対するデフォルト ゲートウェイとしてそのインターフェースを設定します。
ゲートウェイ出力を通じてサービスにアクセスするには、ターゲットの IP アドレスまたはホスト名を使用します。 例：
wget actp://wordpress.com/latest.tar.gz
ほとんどのアプライアンスでは、ゲートウェイ出力端子がネットワークにアクセスするために使用されます。 また、企業ネットワークなどのネットワークにアクセスするためにも使用できます。 ゲートウェイ出力端子の名前は、ゲートウェイの IP アドレス、またはゲートウェイ出力に接続されているアプライアンスによって提供されるルータの IP アドレスに解決されます。 名前も、DNS サーバの名前として使用できます。 たとえば、dig @net google.com Net はゲートウェイ出力端子の名前で、dig は IP アドレスを解決します。
Raw インターフェースは、同じアプリケーション内のアプライアンスと通信する端子とは異なり、アプライアンスの外部と通信します。 これには他のアプライアンスだけでなく外部との通信も含まれます。
Raw インターフェースは、仮想マシンの仮想ネットワーク インターフェースおよび従来のサーバの NIC と非常に似ています。 これらの IP アドレスはアプリケーション設定の一部として割り当てられます。 APK は、Raw インターフェース上の IP アドレスを自動的に設定します。 さらに、APK は IP アドレスに基づいてネットマスクとゲートウェイおよび NAS サーバも自動的に設定します。
アプライアンスに 1 つの Raw インターフェースがある場合は、それがデフォルト ゲートウェイになり、外部ネットワークにアクセスするために使用できます。 アプライアンスは、アプリケーションで設定されているもの以外の IP アドレスを使用できません。 無効な IP アドレスが含まれるパッケージはすべてドロップされます。
1 つの Raw インターフェースで最大 4 つの IP アドレスがサポートされます。
APK は自動的にネットマスクとゲートウェイを設定しますが、この機能は APK の config_extif コマンドを使用して無効にできます。 この機能が無効な場合は、アプライアンス スタートアップ スクリプトで Raw インターフェースのネットワーク設定を設定する必要があります。 割り当てられた設定は、アプライアンス インスタンス記述子ファイルにあります。 Raw インターフェースを無効にする場合、アプライアンスに複数の Raw インターフェースがあり、アプライアンスでルーティングと名前の解決を制御する場合は、自動設定が便利です。
VLANS とネットワーク
Raw インターフェースが特定の VLAN 上に配置されている場合、VLAN タグ付けは AppLogic によって処理されます。 アプライアンスは、802.19 VLAN タグのないパッケージを予期し送信する必要があります。
Legacy Raw Interfaces
バージョン 3.5 より前のバージョンの CA AppLogic® は、外部と呼ばれる 1 つの Raw インターフェースのみをサポートしていました。 このインターフェースは、外部インターフェースへのコネクタを必要としませんでした。 それはプロパティによって設定されました。 このレガシー Raw インターフェースは、後方互換性のためにのみサポートされ、新しいアプライアンスでは使用できません。
レガシー Raw インターフェースを設定するには、アプライアンス スタートアップ スクリプトを使用する必要があります。APK ではレガシー Raw インターフェースは自動的に設定されません。IP アドレス、ネットマスク、ゲートウェイ、DNS サーバなどのネットワーク設定は、通常、プロパティの設定によって設定されます。 IP アドレスは、IP アドレスが IP 所有プロパティとして定義されているかどうかに基づいて適用されます。
IP 所有プロパティでは、IP アドレスは許可された範囲内にあるかどうかが検証され、インターフェースが他の IP アドレスを使用することを許可しません。 最大で 4 つの IP 所有プロパティを定義できます。
アプライアンスに IP 所有プロパティがない場合、レガシー Raw インターフェースの IP アドレスは検証または適用されません。 この機能は、IP アドレス ハイジャックを可能にするので、注意して使用する必要があります。 下位互換性のためにのみサポートされています。 サポートは今後のバージョンで削除されるか無効にされる可能性があります。
デフォルトの Raw インターフェース
デフォルトの Raw インターフェースは、イベントを送信し、アプライアンスへの SSH および Web コンソール アクセスを提供します。
アプライアンス境界での各ボリューム設定は、ブロック デバイスとしてアプライアンスに提供されます。 APK は、境界設定で提供されているマウント ポイントを使用して、アプライアンス ファイル システム内のすべてのボリュームを自動的にマウントします。
自動マウント機能は、apk_config_automount オプションによって無効にできます。 詳細については、Linux または Windows でのアプライアンス カスタマイズ動作を参照してください。
デフォルトでは、ボリュームはアプライアンス ファイル システムの次のようにマウントされます。
ほとんどのボリュームは、よりよくレガシー仮想マシン イメージをサポートするため、1 つのボリューム当たり 1 つのパーティションを保持します。 APK はマルチパーティション ボリュームも認識します。
注：
すべての場合、読み取り専用ボリュームはアプライアンスによって変更できません。
リモート ファイル システム、一部のサーバ アプライアンス、Web6 や Tomcat などは、ネットワーク ファイル システムを自動的にマウントできます。 ネットワーク ファイル システムはボリュームとみなされず、マウントのプロセスは APK では実行されませんが、アプライアンス開発者に任せられます。
規則によって、ネットワーク ファイル システムは次のようにマウントされます。
アプライアンスは、重要なイベント変更および異例の出来事を示すためにイベントを送信できます。 たとえば、APK は stderr へのメッセージの印刷により起動成功または失敗のイベントをレポートします。 スタートアップの後、アプライアンスの動作中に VME イベント生成プログラム ユーティリティを使用して追加の情報または警告メッセージを送信できます。 VME は、アプライアンスのブート プロセス中と実行時に特定のイベントを生成するユーザ モード ユーティリティです。 詳細については、vme：イベント ジェネレータを参照してください。
キー イベント
起動完了は最も重要であり、アプライアンスが送信する必要のある唯一のイベントです。 完了とスタートアップで、管理されたアプライアンスは、アプライアンスが正常に設定され開始されたことを示す Started Okay メッセージを送信します。 アプライアンスは、機能を実行する準備ができています。
アプライアンスが Start Failed をサブミットする場合、それは、アプライアンス設定および（または）スタートアップが失敗しており失敗の理由を含む説明メッセージを提供することを示します。 失敗の理由はグリッド ログに格納され、ログ リストまたはダッシュボードの［ログ］タブを使用して参照できます。
APK を使用する場合、vme ユーティリティは AppLogic スクリプトの返されたステータスに基づいて、APK によって自動的に呼び出されます。
そのスクリプトは、アプライアンスが正しく開始した場合は終了コード 0 を返し、アプライアンスが失敗した場合はゼロ以外を返す必要があります。 エラー メッセージを stderr に印刷する必要があります。 APK は、applogic_appliance スクリプトによって印刷されるテキストの最後の行だけをグリッド ログに送信します。 stderr に印刷される他のテキストは、アプライアンス ブート ディスク上の一時ファイルに格納されます。 スクリプトが何も印刷しないが、失敗ステータスを返す場合、APK は開始テキスト メッセージに一般的な失敗を送信します。
vme バイナリを使用して、管理されたアプライアンスを直接開始または失敗できます。 スタートアップの後、vme バイナリはアプライアンス動作中に追加の情報/警告メッセージを送信できます。 詳細については、vme：イベント ジェネレータのセクションを参照してください。
スタートアップ中に、以下に述べるように、アプライアンスはログとアラートを発行する可能性もあります。
ほとんどのアプライアンスは、予測可能な短い時間でスタートアップを完了します。 ただし、アプライアンスは、ブート タイムアウトまたは予測可能な時間に収まらない長い手順を実行する必要がある場合があります。
長い手順を実行する必要のあるアプライアンスは、プロセスを完了するために追加の時間を要求する可能性があります。 例：
アプライアンスが外部のサービスを使用する長いパスを実行する必要がある場合、その要件は予測不能な時間になることがあります。 それをするため、アプライアンスはメンテナンス イベントをサブミットします。 イベントの発行によってアプライアンスがメンテナンス開始モードになると、AppLogic はほとんど不定の量の時間を開始に提供できます。 このモードでは、アプライアンスは定期報告を提供して、ロジックおよびスタートアップの完了パーセンテージを通知します。
アプライアンスがメンテナンス進捗状況イベントの送信により進捗状況を示さない場合、アプライアンスはハングまたは失敗とみなされ、スタートアップはタイムアウトします。 アプライアンスはタイムアウトまで 1 秒および 1 分の間隔で定期メンテナンス更新を提供する必要があります。 進捗状況パーセンテージは増分である必要があります。 メンテナンス操作が完了すると、アプライアンスは起動成功または失敗イベントを示すことによりそのスタートアップを完了し、理由を提供します。
アプライアンスは、異常な状況を検出した場合、グリッド ログにログ メッセージを送信できます。 グリッド ログにイベントを送信するため、アプライアンスは grid_log を使用します。 VME = メッセージの log_text。 アプライアンスは、このイベントを控え目に使用し、IP アドレス競合などのグリッド スコープに影響がある可能性のある重要なイベントに対してのみ使用する必要があります。 アプライアンスは、ログを妨げるのを差し控えるため、グリッド ログにすべての sys ログまたは定期的なイベントを送信しないようにする必要があります。
破滅的または非常に重要なイベントを検出したアプライアンスは、アラート イベントをサブミットする可能性があります。 これにより、ダッシュボードにメッセージが表示され、設定されている場合は、グリッド管理者に電子メールが送信されます。 アプライアンスは、IP アドレス競合、フェールオーバ イベント、データベース検証エラー、停止または回復イベントなどのイベントに対してグリッド アラートを送信する必要があります。
アプライアンスは例外的な発生でのみグリッド アラート イベントを使用する必要があり、定期的なイベントは示さないようにする必要があります。 グリッド コントローラは、あまりにも多数または頻繁にイベントを送信するアプライアンスを抑制する可能性があります。
ccad （カウンタ コレクション エージェント）デーモンを実行するそれぞれのアプライアンスでは、カスタム カウンタを定義して、サードパーティ ユーティリティによって収集できます。 この機能は拡張インターフェースと呼ばれ、標準の MON ユーザ インターフェースによってアプライアンスに固有のカウンタ データをモニタするオプションを、アプライアンス作成者に提供します。
カスタム カウンタをモニタするには、ccad 設定にカウンタ定義を追加して、ccad に実際のカウンタ値を適用します。 オプションの /etc/ccad.conf 設定ファイルでカスタム カウンタを定義する必要があります（UDL 形式）。 設定に変更を加えた場合は、必ず ccad デーモンを再起動して変更を有効にする必要があります。
単純な設定例を以下に示します。
counters Apache
{
pace = 1000
pipe = /tmp/cca
counter Total_Accesses
{
name = "Total hits"
desc = "Total number of hits"
units = "#"
type = "MAX"
}
counter Total_kBytes
{
name = "Total bytes"
desc = "Total number of bytes"
units = "bytes"
type = "MAX"
}
counter BusyWorkers
{
name = "Active requests"
desc = "Number of active requests"
units = "#"
type = "MAX"
}
counter IdleWorkers
{
name = "Idle servers"
desc = "Number of idle servers"
units = "#"
type = "MAX"
}
}
|
Copyright © 2013 CA.
All rights reserved.
|
|