7

SGD サーバー、アレイ、および負荷分散

この章では、SGD サーバーおよびアレイの設定、ライセンス管理、および監視を行う方法について説明します。Administration Console、ログフィルタ、インストールのバックアップなど、SGD のシステム管理機能の一部についても説明します。

この章の内容は、次のとおりです。


アレイ

SGD では、「アレイ」とは、設定情報を共有する一連の SGD サーバーを指します。

アレイには、次のような利点があります。

どの SGD サーバーにログインした場合でも、同じ Webtop が表示され、ユーザーはアプリケーションを再開することができます。

この節の内容は、次のとおりです。

アレイの構造

アレイは、次のサーバーで構成されます。

1 台のスタンドアロンサーバーは、セカンダリサーバーがないアレイ内のプライマリサーバーと見なされます。

アレイ内の SGD サーバーでは、異なるオペレーティングシステムを実行できます。ただし、アレイのすべてのメンバーが、同じバージョンの SGD を実行する必要があります。

SGD の評価期間中は、アレイのメンバーは 2 つまでに制限されます。ライセンスキーをインストールすると、この制限はなくなります。

アレイ内の SGD サーバーはユーザーセッションとアプリケーションセッションに関する情報を共有するため、SGD ホストの時刻を同期させることが重要です。Network Time Protocol (NTP) ソフトウェアまたは rdate コマンドを使用して、すべての SGD ホストの時刻を確実に同期させてください。

アレイ全体へのデータの複製

プライマリサーバーは、セカンダリサーバーにデータを複製する際、次のデータを複製します。

リソースファイルを除く上記のデータは、変更されるとすぐに複製されます。リソースファイルの同期は 1 日 1 回、サーバーの稼働中にのみ実行されます。同期されるリソースファイルは、次のディレクトリにあるファイルです。

プライマリサーバー上のこれらのディレクトリにあるファイルだけを追加、変更、または削除してください。

アレイの同期にかかる時間と労力は、アレイのサイズに直接比例します。リソースの同期を実行する時刻は選択できます。Administration Console では、各 SGD サーバーの「パフォーマンス」タブの「毎日のリソース同期時刻」属性でこれを設定します。

アレイの通信

アレイでは、各 SGD サーバーにピア DNS (ドメインネームシステム) 名と 1 つ以上の外部 DNS 名が割り当てられています。SGD サーバーどうしは、常にピア DNS 名を使用して通信します。SGD の設定ツールでアレイメンバーを指定するときにも、ピア DNS 名を使用します。外部 DNS 名は、SGD Client が SGD サーバーに接続する場合にのみ使用されます。詳細については、DNS 名を参照してください。

アレイ内の SGD サーバー間の接続は、TCP (Transmission Control Protocol) ポート 5427 で行われます。明示的に有効にしないかぎり、この接続は暗号化されません。アレイ内の SGD サーバー間の接続は、アレイ内のセキュア通信を使用して暗号化することができます。SGD サーバー間の接続の保護を参照してください。

アレイ内の各サーバーは、アレイ内のすべての SGD サーバーについてピア DNS 名の記録を保持しています。次の場合、サーバーは TCP ポート5427 でのみ接続を受け入れます。

ほとんどの接続は、プライマリサーバーからセカンダリサーバーに対して行われます。このような接続でデータが複製され、アレイの同期が保たれます。ただし、アレイメンバーはほかのアレイメンバーと直接通信できる必要があります。

アレイに対する SGD サーバーの追加と削除

アレイに対する SGD サーバーの追加や削除は、Administration Console または tarantella array コマンドを使用して行います。

すべてのアレイ操作は、アレイのプライマリ SGD サーバーで実行することが最善です。

procedure icon  アレイにサーバーを追加する方法

アレイに追加するサーバーは、スタンドアロンサーバーでなければなりません。言い換えると、サーバーはアレイ内に単独で存在する必要があります。

  1. プライマリ SGD サーバーで Administration Console にログインします。

  2. 「Secure Global Desktop サーバー」タブに移動します。

  3. 「Secure Global Desktop サーバーのリスト」の「追加」ボタンをクリックします。

    「Secure Global Desktop サーバーの追加」画面が表示されます。



    ヒント - tarantella array join コマンドを使用してアレイに SGD サーバーを追加することもできます。



  4. 「DNS 名」フィールドに、SGD サーバーのピア DNS 名を入力します。

  5. 「ユーザー名」フィールドと「パスワード」フィールドに、SGD 管理者のユーザー名とパスワードを入力します。

  6. 「追加」をクリックします。

    「Secure Global Desktop サーバー」タブが表示されます。

    「Secure Global Desktop サーバー」タブには、サーバーの変更処理と同期処理が完了するまで待つように勧めるメッセージが表示されます。



    注 - アレイの構造に変更を加えた場合は、その変更がアレイ内のすべての SGD サーバーにコピーされるのを待ってから、次の変更を行うようにしてください。プライマリ SGD サーバーで tarantella status コマンドを実行して、アレイの状態を確認してください。



    Advanced Load Management を使用する負荷分散アプリケーションサーバーを追加する場合は、アレイに追加したあとにウォームリスタートを実行する (tarantella restart --warm) 必要があります。Advanced Load Management の仕組み も参照してください。

procedure icon  アレイからサーバーを削除する方法

アレイからプライマリサーバーを削除するには、まず、ほかのサーバーをプライマリサーバーに変更する必要があります。

次に、古いプライマリサーバーをアレイから削除します。

アレイからサーバーを削除すると、サーバーはそのライセンスキーを失います。

  1. プライマリ SGD サーバーで Administration Console にログインします。

  2. 「Secure Global Desktop サーバー」タブに移動します。

  3. 「Secure Global Desktop サーバーのリスト」の「削除」ボタンをクリックします。



    ヒント - tarantella array detach コマンドを使用してアレイから SGD サーバーを削除することもできます。



  4. プロンプトが表示されたら、「了解」をクリックします。

    「Secure Global Desktop サーバー」タブには、サーバーの変更処理と同期処理が完了するまで待つように勧めるメッセージが表示されます。



    注 - アレイの構造に変更を加えた場合は、その変更がアレイ内のすべての SGD サーバーにコピーされるのを待ってから、次の変更を行うようにしてください。プライマリ SGD サーバーで tarantella status コマンドを実行して、アレイの状態を確認してください。



procedure icon  アレイのプライマリサーバーを変更する方法

  1. プライマリ SGD サーバーで Administration Console にログインします。

  2. 「Secure Global Desktop サーバー」タブに移動します。

  3. 「Secure Global Desktop サーバーのリスト」の「プライマリ化」ボタンをクリックします。



    ヒント - tarantella array make_primary コマンドを使用してアレイのプライマリサーバーを変更することもできます。



  4. プロンプトが表示されたら、「了解」をクリックします。

    「Secure Global Desktop サーバー」タブには、サーバーの変更処理と同期処理が完了するまで待つように勧めるメッセージが表示されます。

    以前のプライマリサーバーは、セカンダリサーバーになります。



    注 - アレイの構造に変更を加えた場合は、その変更がアレイ内のすべての SGD サーバーにコピーされるのを待ってから、次の変更を行うようにしてください。プライマリ SGD サーバーで tarantella status コマンドを実行して、アレイの状態を確認してください。



アレイとサーバーの設定

Administration Console では、アレイと SGD サーバーの設定を行うことができます。「グローバル設定」タブにある属性は、アレイ全体に適用される設定です。これには、ユーザーが SGD に対して認証を行う方法などが含まれます。付録 A には、すべてのグローバル設定の詳細が記載されています。「Secure Global Desktop サーバー」タブで SGD サーバーの名前をクリックすると、そのサーバーの外部 DNS 名など、そのサーバーだけに適用される属性が表示されます。付録 B には、すべてのサーバー固有設定の詳細が記載されています。

コマンド行から tarantella config コマンドを使用して、グローバル設定やサーバー固有の設定を一覧表示したり編集したりすることもできます。


負荷分散

負荷分散を使用すると、シングルポイント障害を発生させることなく、信頼性に優れた、高性能なサービスを受けることができるように、サポート対象のユーザー数を増やすことができます。

SGD では、次の負荷分散メカニズムがサポートされています。

ユーザーセッションの負荷分散

ユーザーセッションの負荷分散は、ログイン先の SGD サーバーの選択に関連しています。ユーザーは、アレイ内の任意の SGD サーバーにログインして、同じアプリケーションにアクセスできます。

ユーザーセッションの負荷分散は、SGD に最初に接続する前に行われます。多数の機構を使って、適切な SGD サーバーを選択できます。次に例を示します。

ユーザーセッションの負荷分散におけるもっとも重要な要素は、セッションの持続性です。ユーザーセッションは、ユーザーが SGD サーバーにログインした時点で始まり、そのサーバーによって所有されます。ユーザーが SGD とやりとりすると、さらに要求が HTTP (Hypertext Transfer Protocol) 接続を介して SGD サーバーに送信されます。ネットワーク接続の負荷分散が行われている場合、HTTP 要求はアレイ内の任意の SGD サーバーに転送される可能性があります。HTTP 要求がそのユーザーセッションを所有していない SGD サーバーに送信されると、次のことが発生する可能性があります。

ユーザーセッションの負荷分散を正常に行うには、HTTP 要求が常に正しい SGD サーバーに送信されるように「持続」する必要があります。

SGD のデフォルトインストールでは、HTTP 接続を持続させるためには負荷分散 JSP を使用して追加設定を行う必要があります。JSP には Cookie を設定する JavaScript スクリプトが含まれており、その Cookie は HTTP 要求を正しいサーバーにリダイレクトするために使用されます。

負荷分散 JSP は、次の条件が満たされている場合にのみ使用できます。

負荷分散 JSP は、次の方法で使用できます。

負荷分散 JSP を使用してユーザーセッションを分散する

負荷分散 JSP を使用してユーザーセッションを分散する場合は、アレイメンバーの 1 つが負荷分散サーバーとして機能します。通常、これはアレイのプライマリサーバーです。負荷分散サーバーで、ユーザーセッションをホストできる SGD サーバーのリストを使用して負荷分散 JSP を設定します。ユーザーが負荷分散サーバーに接続すると、負荷分散 JSP はラウンドロビン機構を使用してリスト内の SGD サーバーにユーザーをリダイレクトします。

ユーザーは、負荷分散 JSP に接続する URL を使用して負荷分散サーバーに接続する必要があります。通常、これは http://server.example.com/sgd です。ここで、server.example.com は SGD サーバーの名前です。

HTTPS (Hypertext Transfer Protocol over Secure Socket Layer) 接続を使用するには、SGD を次のように設定します。

  • 負荷分散サーバーに対して、HTTP 接続を使用します。

  • 負荷分散 JSP で SGD サーバーの HTTPS URL (Uniform Resource Locator)を設定します。

procedure icon  負荷分散 JSP を設定してユーザーセッションを分散する方法

負荷分散サーバーとして機能するアレイメンバーを 1 つ選択します。次の手順では、アレイのプライマリ SGD サーバーを使用しています。

  1. アレイの「プライマリ」 SGD サーバーにスーパーユーザー (root) としてログインします。

  2. 負荷分散 JSP ファイルを /sgd Web アプリケーションディレクトリにコピーします。

    次に例を示します。


    # cd /opt/tarantella/webserver/tomcat/5.0.28_axis1.2/webapps/sgd/
    # cp -rp admin/loaddist/ swcd/
    



    注 - ファイルをコピーする際は、-p オプションを使用して、ファイルのアクセス権を保持してください。



  3. 負荷分散 JSP を編集します。

    負荷分散 JSP は swcd.jsp です。

    1. 負荷分散の対象となる SGD サーバーの外部 DNS 名を追加します。

      詳細については、外部 DNS 名の設定を参照してください。

      hosts = new Array セクションを修正します。次に例を示します。

      hosts[0] = "http://www1.example.com"
      hosts[1] = "http://www2.example.com"
      ...
      hosts[4] = "http://www5.example.com"

      セキュリティー保護された接続を使用している場合は、URL が https:// で始まっていることを確認してください。

      プライマリサーバーでユーザーセッションをホストする場合にのみ、プライマリ SGD サーバーをリストに含めてください。

    2. LBHOST 変数を設定します。

      次のように、最初のコメント記号 (//) を削除します。

      var LBHOST = null // Not in Load Balancer/Round Robin DNS mode

    3. 変更を保存します。

  4. 負荷分散 JSP を使用するよう SGD エントリポイント JSP を設定します。

    エントリポイント JSP は index.jsp です。

    1. 最初の行を次のように変更します。

      <%@ include file="swcd/swcd.jsp" %>

    2. 変更を保存します。

外部機構を使用してユーザーセッションを分散する

ハードウェアロードバランサやラウンドロビン DNS などの外部機構を使用してユーザーセッションの負荷分散を行う場合は、次の要素が重要になります。

  • 外部 DNS 名。アレイ内の SGD サーバーに、外部 DNS 名で直接アクセスできる必要があります。外部ロードバランサがファイアウォール、スイッチ、またはルーターとして機能している場合は、外部 DNS 名によるアクセスを許可するよう設定する必要があります。外部 DNS 名の設定を参照してください。

  • AIP (Adaptive Internet Protocol) 接続。AIP 接続はアプリケーションセッションをホストしている SGD サーバーに転送される必要があります。外部ロードバランサは、アレイ内のほかの SGD サーバーに接続を分散してはいけません。

  • AIP は HTTP ではありません。SGD セキュリティーサービスを有効にすると、AIP 接続は SSL (Secure Sockets Layer) を使用して暗号化されます。外部ロードバランサは、AIP 要求の SSL を復号化する場合、残りの内容を処理することはできません。

  • URL リライティング。外部ロードバランサは、URL を書き換えるよう設定できます。SGD サーバーの外部 DNS 名と一致しないホスト名を含んでいる URL を使用して SGD に接続する場合、その影響は不明です。

  • 複数の HTTPS 接続の仮想ホスティング。外部ロードバランサおよび SGD Web サーバーに対して HTTPS 接続を使用するには、2 つの証明書が必要です。1 つはロードバランサの DNS 名の証明書、もう 1 つは SGD サーバーの外部 DNS 名の証明書です。これを行うには、仮想ホスティングを使用して、同じホスト上に 2 つの Web サーバーをそれぞれ異なる DNS 名で作成します。ただし、これらの Web サーバーでは、異なる TCP ポートまたは異なる IP (Internet Protocol) アドレスを使用する必要があります。

外部機構を使用してユーザーセッションを分散するには、アレイ内のすべての SGD サーバーで負荷分散 JSP の設定を行います。

ハードウェアロードバランサを使用している場合は、SGD サーバーに外部 DNS 名でアクセスすることを許可するようにロードバランサを設定する必要があります。通常、ロードバランサは SSL アクセラレータでもあります。この構成では、SGD への接続は次のように処理されます。

  1. ユーザーは、ロードバランサの DNS 名に HTTPS 接続を確立します。

  2. ロードバランサは、SSL 要求を復号化し、選択された SGD サーバーの外部 DNS 名に HTTP 要求として転送します。

  3. SGD サーバーの負荷分散 JSP は、負荷分散 Cookie を調べ、必要に応じて HTTP 要求を正しい SGD サーバーにリダイレクトします。

ユーザーは、ロードバランサの DNS 名を含んでいる URL を使用して SGDに接続する必要があります。たとえば、https://loadbalancer.indigo-insurance.com/sgd です。

SGD セキュリティーサービスが有効になっており、かつ外部ロードバランサが SSL 接続を復号化して、それを暗号化されていない接続として転送するよう設定されている場合は、セキュリティー保護されたポートでプレーンテキスト接続を受け入れるようアレイの各 SGD サーバーを設定する必要があります。詳細については、外部 SSL アクセラレータの使用を参照してください。

ロードバランサと SGD サーバーの間で HTTPS 接続を使用するには、負荷分散 JSP 内の URL が https:// で始まっていることを確認してください。その後、次のいずれかの設定を行います。

  • 負荷分散された HTTPS 接続を終了してから、SGD サーバーの外部 DNS 名に対する HTTPS 接続として接続を再生成するよう、外部ロードバランサを設定します。

  • SGD ホストに追加の IP アドレスを割り当て、このアドレスを使用するようホストを設定します。追加の IP アドレスで待機するよう SGD Web サーバーを設定し、ロードバランサの証明書をこのアドレスに関連付けます。SGD サーバーの外部 DNS 名をサーバーの元の IP アドレスに関連付けるよう SGD Web サーバーを設定します。追加の IP アドレスを使用するようロードバランサを設定します。

SGD をファイアウォール越えモードで使用すると、外部ロードバランサの使用時に必要となる構成を簡素化することにも役立ちます。ファイアウォール越えでは、SGD への HTTP 接続と AIP 接続がすべて単一のポート (通常は TCP ポート 443) 経由で確立されます。ファイアウォール越えの使用を参照してください。

procedure icon  外部負荷分散メカニズムのために負荷分散 JSP を設定する方法

次示す手順は、外部負荷分散メカニズムを使用している場合に SGD サーバーの負荷分散 JSP を設定する手順例です。

アレイ内のすべての SGD サーバーを同じ方法で設定する必要があります。

  1. SGD ホストにスーパーユーザー (root) としてログインします。

  2. 負荷分散 JSP ファイルを /sgd Web アプリケーションディレクトリにコピーします。

    次に例を示します。


    # cd /opt/tarantella/webserver/tomcat/5.0.28_axis1.2/webapps/sgd/
    # cp -rp admin/loaddist/ swcd/
    



    注 - ファイルをコピーする際は、-p オプションを使用して、ファイルのアクセス権を保持してください。



  3. 負荷分散 JSP を編集します。

    負荷分散 JSP は swcd.jsp です。

    1. 負荷分散の対象となる SGD サーバーの外部 DNS 名を追加します。

      詳細については、外部 DNS 名の設定を参照してください。

      hosts = new Array セクションを修正します。次に例を示します。

      hosts[0] = "http://www1.example.com"
      hosts[1] = "http://www2.example.com"
      ...
      hosts[4] = "http://www5.example.com"

    2. LBHOST 変数を設定します。

      最初のコメント記号 (//) を削除し、SGD サーバーの外部 DNS 名を入力します。次に例を示します。

      var LBHOST = "http://www1.example.com" // LB mode

    3. 変更を保存します。

  4. 負荷分散 JSP を使用するよう SGD エントリポイント JSP を設定します。

    エントリポイント JSP は index.jsp です。

    1. 最初の行を次のように変更します。

      <%@ include file="swcd/swcd.jsp" %>

    2. 変更を保存します。

procedure icon  負荷分散 JSP を My Desktop で使用できるように設定する方法

My Desktop の機能の詳細については、My Desktop の使用を参照してください。

アレイ内のすべての SGD サーバーを同じ方法で設定する必要があります。

  1. SGD ホストにスーパーユーザー (root) としてログインします。

  2. 負荷分散 JSP ファイルを /sgd/mydesktop Web アプリケーションディレクトリにコピーします。

    次に例を示します。


    # cd /opt/tarantella/webserver/tomcat/5.0.28_axis1.2/webapps/sgd/
    # cp -rp admin/loaddist/ mydesktop/swcd/
    



    注 - ファイルをコピーする際は、-p オプションを使用して、ファイルのアクセス権を保持してください。



  3. 負荷分散 JSP を使用するように My Desktop を設定します。

    1. My Desktop のエントリポイント JSP の名前を変更します。

      エントリポイント JSP は mydesktop/index.jsp です。

      次に例を示します。


      # mv mydesktop/index.jsp mydesktop/mydesktop.jsp
      

    2. My Desktop の新しいエントリポイント JSP を作成します。

      次の内容を含む新しい JSP ファイル mydesktop/index.jsp を作成します。

      <%@ include file="/mydesktop/swcd/swcd.jsp" %>

    3. My Desktop の JSP ファイルのファイルアクセス権を確認します。


      # chmod root:ttaserv mydesktop/index.jsp mydesktop/mydesktop.jsp
      

  4. 負荷分散 JSP を編集します。

    負荷分散 JSP は mydesktop/swcd/swcd.jsp です。

    1. 負荷分散の対象となる SGD サーバーの外部 DNS 名を追加し、LBHOST 変数を設定します。

    2. TARGET 変数を設定します。

      ユーザーを Webtop にではなく My Desktop に送るように、TARGET 変数を変更する必要があります。

      var TARGET="/sgd/mydesktop/mydesktop.jsp"

    3. 変更を保存します。

負荷分散 JSP の追加の設定

ここでは、負荷分散 JSP で使用できる追加の設定について説明します。

別の Webtop を使用する

負荷分散 JSP は、ユーザーを標準 Webtop に接続します。カスタマイズされた Webtop など、別の Webtop を使用するには、次の行を修正します。

var TARGET="/sgd/standard.jsp"

ローカライズされたスプラッシュ画面

負荷分散 JSP は、/sgd/swcd/ ディレクトリにある画像を使用して英語のスプラッシュ画面を表示します。ローカライズされたスプラッシュ画面を表示するには、スプラッシュ画面画像のデフォルトの格納場所を次の行で変更します。

// ** Location of gif files
<%
// If the gifs are located in the locale dependent resource use the Path below
String path = getContextPath(request) + "/resources/images/splash/locale=" +
getBestSupportedLocale(request) + "/";
// Default location
//String path = "swcd/";
%>

その他の変数

次に、負荷分散 JSP で使用されるその他の変数を示します。

  • SGDLDCOOKIE

    負荷分散のために使用される Cookie の名前。

    デフォルトは SGD_SWCDCOOKIE です。

  • TIMEOUT

    負荷分散 JSP が、選択されたホストの SGD Web サーバーから応答を待つ時間 (ミリ秒単位)。このタイムアウト時間が経過すると、リスト内の次のホストが試されます。

    デフォルトは 10000 ミリ秒です。

  • TESTGIF

    負荷分散 JSP が、選択されたホストの SGD Web サーバーから取得を試みるファイル。これは、ホストが使用可能かどうかを調べるために使用されます。

    デフォルトは /sgd/resources/images/webtop/secure.gif です。

アプリケーションセッションの負荷分散

アプリケーションセッションの負荷分散は、アプリケーションセッションを管理する SGD サーバーの選択に関連しています。

アプリケーションセッションは、セッションを開始したユーザーのユーザー識別情報、プロトコルエンジンプロセスといった、セッションに関する一連のデータで構成されます。プロトコルエンジンプロセスは SGD サーバー上で実行され、次のタスクを実行します。

プロトコルエンジンプロセスは、アレイ内の任意の SGD サーバー上で実行することができます。これはユーザーセッションをホストしているサーバー、つまりユーザーがログインした SGD サーバーと同じである必要はありません。

SGD は、アレイ内のすべての SGD サーバーにわたってアプリケーションセッションの負荷を分散できます。サーバーが多ければ多いほど、各メンバーの負荷は低くなります。Administration Console では、アプリケーションセッションの負荷分散を「グローバル設定」 → 「パフォーマンス」タブで設定します。アプリケーションセッションをホストする SGD サーバーを選択するための方法として、次のいずれかを使用するように SGD を設定できます。

デフォルトでは、SGD はユーザーセッションをホストしているサーバーを使用してアプリケーションセッションの負荷分散を行います。

アプリケーションの負荷分散

アプリケーションの負荷分散は、次の処理に関連しています。

SGD 管理者は、アプリケーションを実行できるアプリケーションサーバーを定義し、使用する負荷分散方式を選択することによって、アプリケーションの負荷分散を管理します。

アプリケーションを実行するアプリケーションサーバーを定義する

アプリケーションオブジェクトにアプリケーションサーバーオブジェクトを割り当てることによって、そのアプリケーションを実行できるアプリケーションサーバーを定義します。

Administration Console では、この操作を、アプリケーションの「ホストしているアプリケーションサーバー」タブで実行します。あるいは、アプリケーションをアプリケーションサーバーに割り当てることもできます。この操作は、アプリケーションサーバーオブジェクトの「ホストされているアプリケーション」タブで実行します。

また、アプリケーションのグループをアプリケーションサーバーに割り当てたり、アプリケーションサーバーのグループをアプリケーションに割り当てたりすることもできます。グループは、アプリケーションサーバーのプール (アプリケーションサーバーファームとも呼ばれる) や、アプリケーションのプールを作成する場合に役立ちます。

Administration Console では、アプリケーションサーバーオブジェクトの「一般」タブで「アプリケーション起動」チェックボックスを選択および選択解除することもできます。これによって、アプリケーションサーバーが、アプリケーション実行可能またはアプリケーション実行不可能としてマークされます。これは、たとえば、保守作業中にサーバーを一時的に使用不可にする場合に有効です。

負荷分散方式を選択する

SGD がユーザーにとって最適なアプリケーションサーバーを決定する際に使用する負荷分散方式を選択します。

Administration Console では、デフォルトの負荷分散方式を「グローバル設定」 → 「パフォーマンス」タブで設定します。個々のアプリケーションに対しては、アプリケーションオブジェクトの「パフォーマンス」タブで異なる方式を選択することによって、グローバル負荷分散方式を上書きすることができます。

SGD がデフォルトで使用する方式は、各サーバーが SGD 経由でホストしているアプリケーションセッションの個数を数え、セッション数のもっとも少ないサーバーを選択することで、アプリケーションの負荷分散を行います。SGD はまた、ユーザーがアプリケーションを起動した時点の「アプリケーションサーバーの実際の負荷」に基づいてアプリケーションの負荷分散を行うための方式も提供できます。これは Advanced Load Management と呼ばれます。Advanced Load Management を使用するには、すべてのアプリケーションサーバーに SGD 拡張モジュールをインストールする必要があります。

負荷分散方式およびほかの要因が負荷分散にどのように影響するかについての詳細は、アプリケーションの負荷分散の仕組み を参照してください。

負荷分散グループ

SGD は、負荷分散グループを使用して、SGD サーバーとアプリケーションサーバー間で高速リンクを使って接続を確立します。

SGD のプロトコルエンジンは、アプリケーションサーバーと SGD サーバー間で使用されるネイティブプロトコル (X11 など) を、SGD サーバーとクライアントデバイス間で使用される AIP に変換します。AIP は低帯域幅用に最適化されていますが、ネイティブプロトコルは最適化されていません。

ネットワークに低速リンクが含まれている場合は、負荷分散グループを使用して、アプリケーションのパフォーマンスを向上させることができます。負荷分散グループは、SGD サーバーとアプリケーションサーバーをまとめてグループ化するために使用します。ユーザーがアプリケーションを実行すると、SGD は、そのアプリケーションサーバーと同じグループにある SGD サーバー上でプロトコルエンジンプロセスを稼働させることを試みます。この処理は、グループ内のすべてのアプリケーションサーバーと SGD サーバーが高速リンクで接続されている場合に最適に機能します。

Administration Console では、負荷分散グループを、SGD サーバーまたはアプリケーションサーバーの「パフォーマンス」タブで定義します。負荷分散グループ名は単に、文字列または文字列のコンマ区切りリストです。この名前は、世界の地名や建物のコードなど、どのようなものでもかまいません。

アプリケーションの負荷分散の仕組み

アプリケーションの負荷分散は、特定のアプリケーションのパフォーマンスを最適化するためのアプリケーションサーバーを選択することが目的です。アプリケーションを起動するときに、アプリケーションオブジェクトの「ホストしているアプリケーションサーバー」タブに指定されているアプリケーションサーバーを使用して、アプリケーションサーバーの候補リストが作成されます。次に、SDG によりこれらのうちユーザーにもっとも適した候補が決定されます。このとき、次の点が考慮されます。

以降の節では、これらの項目および SGD の設定がアプリケーションサーバーの選択にどのように影響するかについて説明します。

アプリケーションサーバーが使用できるかどうか

アプリケーションが起動するときに、アプリケーションサーバーの候補リストの中で、現在使用できないサーバーがあるかどうかが SDG により確認されます。使用できないアプリケーションサーバーは、リストから削除されます。

SGD 管理者は、Administration Console でアプリケーションサーバーオブジェクトの「一般」タブの「アプリケーション起動」チェックボックスを選択解除することにより、そのアプリケーションサーバーを使用不可として指定することができます。この作業は、アプリケーションサーバーの保守中にアプリケーションサーバーを使用できない状態にする場合などに行ないます。

SGD Advanced Load Management を使用している場合は、負荷分散サービスから SGD に定期的に keep alive パケットが送信されます。これらのパケットが停止したアプリケーションサーバーについては接続が切断されていると見なされ、負荷分散サービスが接続を再度確立するまで「使用できない」サーバーとして処理されます。

負荷分散グループ

負荷分散グループは、SGD サーバーとアプリケーションサーバーをまとめてグループ化するために使用します。ユーザーがアプリケーションを実行すると、SGD は、そのアプリケーションサーバーと同じ負荷分散グループにある SGD サーバー上でプロトコルエンジンプロセスを稼働させることを試みます。この処理は、グループ内のすべてのアプリケーションサーバーと SGD サーバーが高速リンクで接続されている場合に最適に機能します。

詳細については、負荷分散グループ を参照してください。

サーバーアフィニティー

アプリケーションの起動時には、そのユーザーがいずれかのアプリケーションサーバー上でほかのアプリケーションをすでに実行中であるかどうかが考慮されます。この作業は、サーバーアフィニティーと呼ばれます。サーバーアフィニティーとは、ユーザーが最後に起動したアプリケーションと同じアプリケーションサーバー上で、アプリケーションを起動しようとすることです。



注 - サーバーアフィニティーが有効に機能するには、アプリケーションが同じアプリケーションサーバーセットに関連付けられている必要があります。



サーバーアフィニティーはパーセントで表現されます。現在設定できる値は次の 2 つだけです。

  • 0 - 実行中のアプリケーションはアプリケーションサーバーの選択に影響しません。

  • 100 - 選択されたアプリケーションを実行するときに、既存のアプリケーションサーバーができるだけ再利用される必要があります。これはデフォルト値です。

サーバーアフィニティーの値を変更するには、次のコマンドを実行します。


$ tarantella config edit \
--tarantella-config-applaunch-appserveraffinity 0|100



caution icon

注意 - Windows アプリケーションを使用している場合、この値を変更することはお勧めしません。これは、複数のアプリケーションサーバーを使用する場合に、問題 (特にローミングプロファイルの問題) が発生するためです。また、同じアプリケーション群に属する複数のアプリケーションを互いに異なるサーバー上で実行すると、ライセンスの問題が発生することがあります。



アプリケーションサーバーの相対的な処理能力

SGD では、アプリケーションサーバーの相対的な処理能力を考慮して、アプリケーションの起動場所を決定できます。

相対的な処理能力は、パーセントで表現されます。デフォルトでは、すべてのサーバーに値 100 が割り当てられます。サーバーの負荷分散プロパティー weighting を編集してその負荷係数を増減すると、SGD によってアプリケーションサーバーが選択される可能性を増減できます。負荷係数の詳細については、アプリケーションの負荷分散の調整を参照してください。

アプリケーションサーバーの相対的な処理能力を使用して、次の操作を実行できます。

  • 特定のサーバー上で起動するアプリケーションセッションの数を減らす。たとえば、特定のサーバーを SGD 以外のプロセスで使用する場合に、この操作を行います。

  • 特定のサーバー上で起動するアプリケーションセッションの数を増やす。たとえば、あるサーバーが CPU 容量は小さくても IO(入出力) 性能が優れている場合に、この操作を行います。

負荷係数の使用方法の詳細については、もっとも負荷の少ないアプリケーションサーバー の負荷計算を参照してください。

相対的な処理能力の計算例 1

2 つのアプリケーションサーバー london および paris が動作しています。paris の負荷係数は 50 で、london の負荷係数は 100 です。その他のアプリケーション起動条件がすべて満たされていて、現時点でサーバーの負荷が同じ場合には、アプリケーションを起動するために選択される可能性は london の方が高くなります。

相対的な処理能力の計算例 2

100 個のアプリケーションサーバーが動作していて、その中の 1 つだけを「より強力な」サーバーとして割り当てるとします。そのサーバーの負荷係数を 200 に増やします。

もっとも負荷の少ないアプリケーションサーバー

SGD では、もっとも負荷の少ないアプリケーションサーバーを選択する方式がいくつかサポートされています。

デフォルトの方式は、Administration Console の「グローバル設定」 → 「パフォーマンス」タブで設定します。アプリケーションオブジェクトの「パフォーマンス」タブに異なる方式を指定することで、デフォルトを上書きできます。この方法を利用すれば、アプリケーションの負荷分散をさまざまな方法で行うことができます。

アプリケーションの負荷分散の方式として、次のものがサポートされています。

  • 最少アプリケーションセッション数

  • 最小 CPU 使用量

  • 最大空きメモリー

「最小 CPU 使用量」方式および「最大空きメモリー」方式では、ユーザーがアプリケーションを起動した時点の「アプリケーションサーバーの実際の負荷」が計算されます。これは Advanced Load Management と呼ばれます。詳細については、Advanced Load Management の仕組みを参照してください。

最少アプリケーションセッション数

「最少アプリケーションセッション数」方式を使用した場合は、実行中のアプリケーションセッションがもっとも少ないアプリケーションサーバーが選択されます。この選択は、SGD から運用しているアプリケーションセッション数のみに基づいて行われます。

これはデフォルトの方式です。

アプリケーションの起動時にアレイからアプリケーションサーバーの負荷情報を取得できないなどの理由で、Advanced Load Management の使用で問題が発生した場合は、代わりに「最少アプリケーションセッション数」方式が使用されます。こうした状況は、プライマリ SGD サーバーを再起動しているときなどに発生することがあります。

アプリケーションサーバーの負荷計算には、次の数式が使用されます。

アプリケーションセッションの数 x 100 / サーバーの負荷係数

最少アプリケーションセッション数を使用した負荷計算の例

ここでは、アプリケーション負荷分散の「最少アプリケーションセッション数」方式を使用して負荷を計算する例を紹介します。

現在、アプリケーションサーバー london では 10 個のアプリケーションセッションが動作しています。負荷係数値は 100 です。

現在、アプリケーションサーバー paris では 12 個のアプリケーションセッションが動作しています。負荷係数値は 100 です。

london の負荷値は、次のとおりです。

10 x 100 / 100 = 10

paris の負荷値は、次のとおりです。

12 x 100 / 100 = 12

その他のアプリケーション起動条件が満たされている場合は、それ以降の 2 つのアプリケーションセッションの起動に london が使用されます。london のサーバー負荷係数値を 50 に下げた場合、london の負荷は 20 (10 x 100 / 50) になるため、それ以降の 8 個のアプリケーションセッションの起動には paris が選択されます。

最小 CPU 使用量

「最小 CPU 使用量」方式を使用した場合は、CPU アイドル時間のもっとも長いアプリケーションサーバーが選択されます。この方式は、プロセッササイクルを大量に必要とするアプリケーションに適しています。

この方式では、アプリケーションサーバーの負荷が CPU 性能 (単位は BogoMips) および CPU 使用量に基づいて測定されます。測定は、負荷分散サービスが行ないます。

使用可能な容量の計算には、次の数式が使用されます。

(BogoMips x CPU アイドル率) x 負荷係数 / 100

最小 CPU 使用量を使用した負荷計算の例

ここでは、アプリケーション負荷分散の「最小 CPU 使用量」方式を使用して負荷を計算する例を紹介します。

アプリケーションサーバー london の CPU 性能は 500 BogoMips、サーバー負荷係数値は 75、CPU アイドル率は 25% です。

アプリケーションサーバー paris の CPU 性能は 100 BogoMips 、サーバー負荷係数値は 100、CPU アイドル率は 50% です。

london の使用可能な容量は、次のとおりです。

(500 x 25) x 75 / 100 = 9375

paris の使用可能な容量は、次のとおりです。

(100 x 50) x 100 / 100 = 5000

その他のアプリケーション起動条件が満たされている場合は、paris の方が CPU 使用率が低く、サーバーの負荷係数値が高くても、london がアプリケーションサーバーとして選択されます。

最大空きメモリー

「最大空きメモリー」方式を使用した場合は、空き仮想メモリー容量のもっとも多いアプリケーションサーバーが選択されます。この方式は、大量のメモリーを必要とするアプリケーションに適しています。

この方式では、アプリケーションサーバーの実仮想メモリーと現在使用中のメモリー容量を比較して、アプリケーションサーバーの負荷が測定されます。測定は、負荷分散サービスが行ないます。

使用可能な容量の計算には、次の数式が使用されます。

仮想メモリーの空き容量 x 負荷係数 / 100

最大空きメモリーを使用した負荷計算の例

ここでは、アプリケーション負荷分散の「最大空きメモリー」方式を使用して負荷を計算する例を紹介します。

アプリケーションサーバー london のサーバー負荷係数値は 100、仮想メモリーの空き容量は 250M バイトです。

アプリケーションサーバー paris のサーバー負荷係数値は 75、仮想メモリーの空き容量は 500M バイトです。

london の使用可能な容量は、次のとおりです。

250 x 100 / 100 = 250

paris の使用可能な容量は、次のとおりです。

500 x 75 / 100 = 375

その他のアプリケーション起動条件が満たされている場合は、paris がアプリケーションサーバーとして選択されます。

Advanced Load Management の仕組み

Advanced Load Management では、アプリケーションが起動された時点でそのアプリケーションサーバーに割り当てられている空きメモリー量または空き CPU 時間のどちらかに基づいてアプリケーションの負荷を分散できます。これらの方式を使用して負荷分散を行えるのは、X アプリケーション、Windows アプリケーション、および文字型アプリケーションに対してだけです。

Advanced Load Management を使用するには、すべてのアプリケーションサーバーに SGD 拡張モジュールをインストールする必要があります。これにより、負荷分散サービスがインストールされます。このサービスは、アプリケーションサーバーの CPU やメモリーの負荷に関する情報を SGD にリアルタイムで提供します。また、これは、アプリケーションサーバーが使用不可かどうかを SGD が容易に検出できるようにもします。たとえば、再起動する場合などです。

負荷分散サービスの動作方法の概要を、次に示します。

  1. プライマリ SGD サーバーは、起動するたびに、負荷分散のために考慮する必要のあるアプリケーションサーバーのリストを作成します。このリストは、ホストのアプリケーションへの割り当てまたはアプリケーションからの削除が行われるたびに更新されます。

  2. プライマリ SGD サーバーは、負荷分散対象アプリケーションサーバーのそれぞれに接続し、初期の負荷情報を要求します。そのために、各アプリケーションサーバーの TCP ポート 3579 上の負荷分散サービスに接続します。また、この接続が確立できれば、アプリケーションサーバーがアプリケーションを実行可能であることを確認できたことにもなります。

  3. プライマリ SGD サーバーは、アレイ内のセカンダリサーバーに更新を送信します。この更新には、各方式に対する容量値と、使用不可のアプリケーションサーバーに関する情報が含まれています。

  4. 負荷分散サービスは、UDP ポート 3579 を使用して、定期的な更新をプライマリ SGD サーバーに送信します。この更新は、負荷に変化がない場合でも発生します。この定期的な更新が途絶えるかどうかによって、SGD は、各アプリケーションサーバーがアプリケーションを実行可能かどうかを判断することができます。

  5. プライマリ SGD サーバーは、アレイ内のセカンダリサーバーに定期的な更新を送信します。この更新には、各方式に対する容量値と、使用不可のアプリケーションサーバーに関する情報が含まれています。この更新は、負荷に変化がない場合でも発生します。



    注 - 負荷分散サービスは常に、プライマリ SGD サーバーに対してアプリケーションサーバーの負荷データを送信します。プライマリサーバーが使用不可の場合は Advanced Load Management も使用できないため、セカンダリサーバーは代わりに、セッションに基づくデフォルトの負荷分散に戻ります。



  6. プライマリまたはセカンダリの SGD サーバーは、更新で受け取る負荷情報に基づいてアプリケーションの起動を行います。

アプリケーションの負荷分散の調整

SGD 管理者は、アプリケーションの負荷分散プロパティーを編集することによって、アプリケーションの負荷分散を調整できます。これらのプロパティーは、Advanced Load Management に使用される負荷分散サービスがどのように動作するか、および SGD がアプリケーションサーバーの負荷をどのように計算するかを制御します。アプリケーションの負荷分散をグローバルに調整することも、個々のアプリケーションサーバーに対して調整することもできます。負荷分散プロパティーの編集方法の詳細については、アプリケーションの負荷分散プロパティーの編集 を参照してください。

アプリケーションの負荷分散を調整する前に、必ず次の項目を読み、理解しておいてください。

アプリケーションの負荷分散の動作を次の点で調整することができます。

この調整については、以降の節で説明します。



caution icon

注意 - アプリケーションサーバーの相対的な処理能力の調整を除き、この調整は Advanced Load Management を使用している場合にのみ使用できます。



アプリケーションサーバーの相対的な処理能力

weighting プロパティーを使用すると、アプリケーションサーバーの相対的な処理能力を考慮して、アプリケーションの起動場所を SGD で決定できます。詳細については、アプリケーションサーバーの相対的な処理能力 を参照してください。

負荷分散待機ポート

アレイのプライマリ SGD サーバーは、TCP ポート 3579 を使用してアプリケーションサーバーの SGD 負荷分散サービスと対話します。この動作は、listeningport プロパティーによって制御されます。

負荷分散サービスは、UDP (ユーザーデータグラムプロトコル) ポート 3579 を使用して、更新をプライマリ SGD サーバーに送信します。この動作は、probe.listeningport プロパティーによって制御されます。

これらのポートは Internet Assigned Numbers Authority (IANA) に登録され、SGD 専用として予約されています。これらのプロパティーの変更は、Sun のサポートから依頼された場合にのみ行なってください。プライマリ SGD サーバーとアプリケーションサーバーの間にファイアウォールがある場合は、これらのポートを開く必要があります。

SGD がアプリケーションサーバーに更新を送信するように要求する

connectretries プロパティーは、負荷の更新を要求するために、プライマリ SGD サーバーからアプリケーションへの接続を試みる回数です。試行の間隔は、shorttimeout プロパティーによって制御されます。これらの接続に失敗すると、SGD サーバーは、longtimeout プロパティーに指定されている期間が経過してからもう一度接続を試みます。

たとえば、これらのプロパティーのデフォルトを使用した場合、プライマリ SGD サーバーは、アプリケーションサーバーへの接続を 20 秒間隔 (shorttimeout) で 5 回 (connectretries) 試みます。5 回とも失敗した場合には、600 秒 (longtimeout) 経過してから、20 秒間隔でさらに 5 回の接続を試みます。

アプリケーションサーバーの再起動に時間がかかる場合などには、タイムアウトのプロパティーを変更してみてください。

scaninterval プロパティーは、SGD サーバーの負荷分散対象アプリケーションサーバーリストを走査する間隔を制御しています。走査では、負荷の更新を要求するために通信 (connectretries) する必要があるアプリケーションサーバーが確認されます。

sockettimeout プロパティーは、SGD サーバーが負荷分散サービスへの接続を試みても収集できるデータがなかった場合の、エラーが返されるまでの時間を制御しています。

負荷計算の頻度

probe.samplerate プロパティーと probe.windowsize プロパティーは、負荷分散サービスがアプリケーションサーバーの平均負荷を計算する頻度を制御しています。

たとえば、probe.samplerate を 10 秒、probe.windowsize を 5 に設定するとします。50 秒 (5 x 10) が経過すると、平均値の計算に必要な測定が 5 回実行されています。さらに 10 秒が経過すると、負荷分散サービスは次の測定を実行し、一番古い測定を破棄して新しい平均負荷を計算します。

計算の頻度は、アプリケーションサーバーの負荷が変化する頻度の予測に基づいて増減できます。たとえば、ユーザーが 1 日の始めにアプリケーションを起動し、その日の終わりにアプリケーションを閉じる場合は、負荷計算の頻度を下げます。逆に、ユーザーがアプリケーションの起動と停止を繰り返す場合は、負荷計算の頻度を上げます。

プライマリ SGD サーバーに更新を送信する頻度

replyfrequency プロパティーは、負荷分散サービスがプライマリ SGD サーバーに更新を送信する間隔を制御しています。

percentagechange プロパティーは、使用される CPU/メモリーの増減率のしきい値を制御しています。使用率がこのしきい値以上に増減したら、プライマリ SGD サーバーに報告されるものとします。負荷分散サービスは、使用率が変化するとすぐに、更新を送信します。たとえば、アプリケーションサーバーが 30% の CPU 負荷で動作し、percentchange の値が 10 の場合は、負荷が 20% または 40% になると更新が発生します。負荷分散サービスは、使用率が突然大きく変化する状況にも対応していて、このような場合にも調整を行います。たとえば、percentagechange の値が 20% であるのに、サーバーの CPU 負荷が 81% に達した場合にも対応することができます。

replyfrequency の更新は、負荷が変化していない場合や、percentagechange の更新が発生した場合にも送信されます。percentagechange 計算の基になる値は、replyfrequency の更新が送信されるたびに再設定されます。

updatelimit x replyfrequency 秒の間にアプリケーションサーバーから更新が送信されない場合、SGD はアプリケーションサーバーとの接続が切断されていると見なします。つまり、そのアプリケーションサーバーは、SGD サーバーとの接続を再度確立できる状態になるまでは、アプリケーションを起動できないサーバーと見なされます。

CPU およびメモリーのデータの信頼性

SGD は、updatelimit x replyfrequency 秒の間にアプリケーションサーバーから更新が送信されない場合、CPU およびメモリーに関して受信したデータの信頼性が低いと見なします。



注 - 負荷分散サービスは、負荷が変化していない場合でも更新を送信します。



信頼性の低いデータは、アプリケーションをどのサーバーで起動するかを決定するときに無視されます。つまり、そのアプリケーションサーバーはキューの最後に移動し、アプリケーションを起動するために他のサーバーが利用できないか適切でない場合にだけ使用されます。

アレイのメンバーに更新を送信する頻度

プライマリ SGD サーバーは、maxmissedsamples x replyfrequency/2 秒ごとに、アレイのほかのメンバーに CPU およびメモリーの負荷の更新を送信します。この更新は、負荷が変化していない場合にも実行されます。

1 度でも更新を受け取らなかったセカンダリ SGD サーバーは、保有している負荷データの信頼性を低いと見なし、「最少アプリケーションセッション数」負荷分散方式に戻ります。このサーバーでは、新しい更新を受け取るまでこの方式が使用されます。

アプリケーションの負荷分散プロパティーの編集

SGD のアプリケーション負荷分散は、アプリケーションサーバーの負荷分散のプロパティーを編集することによって調整できます。負荷分散プロパティーは、プロパティーファイルに保存されていて、テキストエディタを使って編集できます。次の 3 つのプロパティーファイルがあります。

この節では、プロパティーファイルの編集方法と編集可能なプロパティーについて説明します。プロパティーの使用方法の詳細については、アプリケーションの負荷分散の調整 を参照してください。



caution icon

注意 - アプリケーションが起動できなくなる可能性があるため、これらのプロパティーを編集する際は慎重に行なってください。



グローバル負荷分散プロパティーファイル

グローバル負荷分散プロパティーファイルには、アレイ内のすべての SGD サーバーに対するデフォルトの負荷分散プロパティーが含まれています。

このファイルは /opt/tarantella/var/serverconfig/global/tier3lb.properties です。



caution icon

注意 - これらの負荷分散プロパティーは、アレイのプライマリ SGD サーバーでのみ編集してください。変更されたプロパティーファイルは、プライマリサーバーからセカンダリサーバーにコピーされます。



tier3lb.properties プロパティーファイルのプロパティーには、tarantella.config.tier3lb.weighting のように、プロパティー名の前に tarantella.config.tier3lb という接頭辞が付いています。

次の表に、変更可能なプロパティーと、SGD が最初にインストールされたときのプロパティーのデフォルト値を示します。また、各プロパティーがどのような目的で使用されるかについても説明します。


プロパティー デフォルト値 目的
connectretries 3 CPU および メモリーの使用量の更新を要求するために、SGD サーバーからアプリケーションサーバーに接続を試みる回数。
listeningport 3579 負荷分散サービスから送信されるデータを待機するために SGD サーバーが使用する UDP ポート。
longtimeout 900 SGD サーバーが次にアプリケーションサーバーへの一連の接続を試みるまでの一時停止期間 (秒)。
maxmissedsamples 20 失われたサンプルの数。アプリケーションサーバーに関する CPU および メモリーのデータの信頼性を計算するために使用されます。
probe.listeningport 3579 SGD サーバーからの要求 (更新の送信をいつ開始するか、など) を待機するときに負荷分散サービスが使用する TCP ポート。
probe.percentchange 10 使用される CPU および メモリーの増減率のしきい値。使用率がこのしきい値以上に増減したら、SGD サーバーに報告されるものとします。
probe.replyfrequency 30 負荷分散サービスが測定した CPU およびメモリーの値を SGD サーバーに送信する間隔 (秒)。このプロパティーの最小値は 2 です。
probe.samplerate 15 CPU およびメモリーを測定する間隔 (秒)。このプロパティーの最小値は 1 です。
probe.windowsize 3 CPU およびメモリーの平均使用率を計算するために使用される、CPU およびメモリーの測定回数。このプロパティーの最小値は 1 です。
scaninterval 60 SGD サーバーの負荷分散対象アプリケーションサーバーリストを走査する間隔 (秒)。
shorttimeout 60 SGD サーバーが次にアプリケーションサーバーへの接続を試みるまでの間隔 (秒)。
sockettimeout 5 ソケットのタイムアウト (秒)。
updatelimit 5 負荷分散サービスがいつ更新データの送信を停止したかの計算に使用される制限。
weighting 100 負荷測定の重み付け (他のアプリケーションサーバーに対する相対値)。

次のプロパティーも tier3lb.properties プロパティーファイルにありますが、決して変更しないでください。

tarantella.config.name=tier3lb
tarantella.config.type=server

アプリケーションサーバーの負荷分散プロパティーファイル

アプリケーションサーバー固有の負荷分散プロパティーファイルを作成することにより、グローバル負荷分散プロパティーの一部を上書きできます。このファイルは、アプリケーションサーバーの負荷分散プロパティーファイルを作成する方法 の説明に従って、「手動」で作成する必要があります。

上書きできるグローバルプロパティーは次のとおりです。

  • probe.listeningport

  • probe.percentchange

  • probe.replyfrequency

  • probe.samplerate

  • probe.windowsize

  • weighting

サーバー固有のプロパティーファイルのプロパティーには、tarantella.config.tier3hostdata.weighting のように、プロパティー名の前に tarantella.config.tier3hostdata という接頭辞が付いています。

procedure icon  アプリケーションサーバーの負荷分散プロパティーファイルを作成する方法

SGD サーバーにログインしているユーザーがいないことと、中断しているアプリケーションセッションも含め、SGD サーバー上で実行されているアプリケーションセッションがないことを確認します。

  1. プライマリ SGD サーバーにスーパーユーザー (root) としてログインします。



    caution icon

    注意 - 負荷分散プロパティーファイルは、アレイ内のプライマリ SGD サーバーでのみ作成してください。このファイルは、プライマリサーバーからセカンダリサーバーにコピーされます。



  2. /opt/tarantella/var/serverconfig/global/t3hostdata ディレクトリに移動します。

  3. 負荷分散プロパティーファイルを作成します。

    template.properties ファイルをコピーして、同じディレクトリに hostname.properties という名前のファイルを作成します。ここで、hostname はアプリケーションサーバーの名前で、たとえば paris.indigo-insurance.com.properties となります。

  4. 負荷分散プロパティーファイルを編集します。

    1. プロパティーファイルをテキストエディタで開きます。

    2. アプリケーションサーバーの完全修飾名を追加します。

      tarantella.config.tier3hostdata.name プロパティーが含まれている行を見つけます。

      =」の後ろに、アプリケーションサーバーの完全修飾名を入力します。

      名前は引用符で囲み、ホスト名の各部分はバックスラッシュを使用してエスケープします。次に例を示します。

      ".../_ens/o\=Indigo Insurance/cn\=paris"

    3. サーバー固有のプロパティーを設定します。

      上書きするプロパティーが含まれている行の「#」を削除して、コメントを解除します。

      コメントを解除するのは、グローバルなデフォルトに変更を加えるプロパティーだけです。

      上書きするプロパティーの値を変更します。



      ヒント - template.properties ファイルには、サーバー固有のファイルを作成するときに役立つコメントが記述されています。



    4. 変更を保存してファイルを閉じます。

  5. プライマリ SGD サーバーをウォームリスタートします。


    # tarantella restart --warm
    

負荷分散サービスのプロパティーファイル

負荷分散サービスのプロパティーファイルには、UNIX または Linux プラットフォームのアプリケーションサーバー上で負荷分散サービスが初回起動時および再起動のたびに使用する設定が含まれています。



caution icon

注意 - これらのプロパティーの変更は、Sun のサポートから依頼された場合か、アプリケーションサーバーの物理メモリーまたは仮想メモリーを変更したときに SGD 拡張モジュールを再インストールしなかった場合のみ行なってください。



負荷分散サービスのプロパティーファイルは /opt/tta_tem/var/serverconfig/local/tier3loadbalancing.properties です。

これらのプロパティーを変更する場合は、手動で負荷分散サービスを停止して再起動する必要があります。

上書きできるプロパティーは次のとおりです。

  • probe.listeningport

  • probe.percentchange

  • probe.replyfrequency

  • probe.samplerate

  • probe.windowsize

  • weighting

負荷分散サービスのプロパティーファイルのプロパティーには、tarantella.config.tier3loadbalancing.weighting のように、プロパティー名の前に tarantella.config.tier3loadbalancing という接頭辞が付いています。


SGD Web サーバー

この節では、SGD に含まれている Web サーバーの設定方法について説明します。この Web サーバーは「SGD Web サーバー」と呼ばれます。

この節の内容は、次のとおりです。

SGD Web サーバーの概要

Web サーバーは SGD をインストールした各ホスト上で稼働させる必要があります。SGD をインストールすると、SGD Web サーバーもインストールされます。

SGD Web サーバーは、SGD で使用できるようにあらかじめ設定された Web サーバーです。SGD Web サーバー は次のコンポーネントで構成されます。


コンポーネント バージョン
Apache HTTP サーバー 2.2.8
OpenSSL 0.9.8g
mod_jk 1.2.25
Apache Jakarta Tomcat 5.0.28
Apache Axis 1.2



注 - Apache Web サーバーには、すべての標準 Apache モジュールが共有オブジェクトとして含まれています。



SGD ホスト上に既存の Web サーバーが存在していても、そのサーバーは SGD Web サーバーの影響を受けません。なぜなら、SGD Web サーバーは別のポート上で待機するからです。

SGD Web サーバーは標準の Apache 指令を使って設定できます。詳細については、Apache documentation を参照してください。

SGD Web サーバーの制御は SGD サーバーとは独立して行いますが、その際、tarantella webserver コマンドを使用します。

SGD での別の Web サーバーの使用

SGD をインストールする際に、SGD Web サーバーをインストールします。この Web サーバーは SGD 用にあらかじめ設定されているので、これを使用することをお勧めします。

SGD に対してユーザー独自の Web サーバーを使用する必要がある場合には、そうすることもできます。ただし、SGD Webtop などのクライアントアプリケーションは、SOAP (Simple Object Access Protocol) プロトコル (over HTTP) を使って SGD サーバーが提供するサービスにアクセスするため、ユーザー独自の Web サーバーを使用する場合でも、SGD Web サーバーを引き続き実行する必要があります

Webtop 用にユーザー独自の Web サーバーを使用するには、Web サーバーと JSP コンテナが必要です。なぜなら、Webtop は JSP アプリケーションだからです。

正常動作する Web サーバーと JSP コンテナの準備が整ったら、Webtop を再配置する際の手順 Webtop を再配置する に従ってください。

SGD Web サーバーのセキュリティー保護

デフォルトでは、SGD Web サーバーはセキュア (HTTPS) Web サーバーとして設定され、SGD セキュリティーサービスに使用されるサーバー証明書を共有します。SGD Web サーバーへの HTTPS 接続の使用を参照してください。

SGD サーバーアレイ内のすべての Web サーバーが、同一の HTTP または HTTPS ポートを使用する必要があります。同一 SGD アレイ内で HTTP Web サーバーと HTTPS Web サーバーを混在させることはできません。

Web サーバーとのセキュリティー保護された接続を有効にした場合、クライアントプロファイルの URL を HTTPS URL に再設定する必要があります。クライアントプロファイルの設定を参照してください。


Administration Console

この節では、SGD 管理者が Administration Console を実行および設定する方法について説明します。

この節の内容は、次のとおりです。

Administration Console の実行

この節では、Administration Console を実行する方法について説明します。Administration Console を使用する際の一般的ないくつかの問題について、回避方法の詳細も説明します。

Administration Console でサポートされるブラウザ

Administration Console を表示するには、SGD でサポートされている、Safari 以外の任意のブラウザを使用できます。SGD でサポートされているブラウザの詳細については、サポートされるクライアントプラットフォーム を参照してください。ブラウザで JavaScript プログラミング言語が有効になっている必要があります。



caution icon

Caution - Administration Console の使用中は、ブラウザの「戻る」ボタンを使用しないでください。代わりに、「オブジェクトビューへジャンプ」リンク、「ナビゲーションビューへジャンプ」リンク、または「オブジェクト履歴」リストを使用して、Administration Console のページ間を移動します。



Administration Console を起動する

Administration Console は、アレイ内のプライマリ SGD サーバー上で実行すると最適に機能します。

Administration Console は、次のいずれかの方法で起動できます。

  • SGD 管理者の Webtop にある Administration Console のリンクをクリックします。

  • http://server.example.com の SGD Web サーバーの開始画面で、「Sun Secure Global Desktop Administration Console の起動」リンクをクリックします。ここで、server.example.com は SGD サーバーの名前です。

  • http://server.example.com/sgdadmin URL にアクセスします。



注 - Administration Console は SGD 管理者専用です。Administration Console を使用するには、SGD 管理者としてログインするか、SGD 管理者としてログイン済みであることが必要です。



ほかの Web アプリケーションコンテナに Administration Console を配備する

Administration Console は、SGD Web サーバーで使用する場合のみサポートされています。

Administration Console には、Web アプリケーションアーカイブ (WAR) ファイル sgdadmin.war が付属しています。このファイルを使って Administration Console を別の Web アプリケーションサーバーに再配備することはできません。

SGD データストアの更新の問題を回避する

アレイ内の任意の SGD サーバーから Administration Console を使用して、SGD データストアに対して新規オブジェクトの作成やオブジェクトの属性の編集といった操作を実行できます。

SGD データストアを編集すると、変更内容がプライマリ SGD サーバーに送信されます。その後、プライマリ SGD サーバーからアレイ内のすべてのセカンダリサーバーに、これらの変更が複製されます。

Administration Console をプライマリ SGD サーバーから実行することで、次の原因による問題を回避できます。

  • 低速なネットワーク - ネットワークが低速な場合、「オブジェクトが見つからない」または「オブジェクトが作成されない」というエラーが返されることがあります。また、設定の変更が正しく反映されないなど、古いデータに関する問題が発生することがあります。

  • プライマリサーバーの停止 - プライマリサーバーが停止した場合や使用できなくなった場合、SGD データストアに加えた変更が適用されないことがあります。

Administration Console を使用してアレイの操作を実行する

アレイの結合や切り離しといったアレイ操作を Administration Console で実行する場合は、次の制限が適用されます。

  • プライマリ SGD サーバーを使用してください。Administration Console をプライマリサーバー上で実行することで、データ複製の問題を回避できます。SGD データストアの更新の問題を回避するも参照してください。

  • アレイ操作に関連するサーバーはすべて稼働している必要があります。たとえば、Administration Console を使用して、停止しているセカンダリサーバーを切り離すことはできません。代わりに、tarantella array detach コマンドを使用してください。

HTTPS 接続でオンラインヘルプを表示する

Administration Console は、JavaHelptrademark ソフトウェアを使ってオンラインヘルプを表示します。ただし、SGD Web サーバーへの HTTPS 接続が有効になっている場合、オンラインヘルプは使用不可になります。

HTTPS 接続を介して JavaHelp を実行するには、SGD Web サーバーの証明書の署名に使用された CA (認証局) 証明書または CA 証明書チェーンが CA 証明書トラストストアに含まれている必要があります。デフォルトでは、SGD Web サーバーは SGD サーバーと同じ証明書を使用します。詳細については、CA 証明書トラストストアを参照してください。

Administration Console の設定

Administration Console Web アプリケーションの配備記述子には、Administration Console の処理を制御する設定が入っています。配備記述子は次のファイルです。

/opt/tarantella/webserver/tomcat/5.0.28_axis1.2/sgdadmin/WEB-INF/web.xml

この節では、ユーザーが設定する可能性のある配備記述子の設定について説明します。設定のほとんどは、<context-param> 要素に含まれているコンテキストパラメータです。web.xml ファイル内のその他の設定は変更しないでください。

配備記述子の設定を操作する場合は、次の点に留意してください。

検索結果の数

com.sun.tta.confmgr.DisplayLimit コンテキストパラメータを使用すると、Administration Console に表示できる検索結果の最大数を設定できます。デフォルト値は 150 です。結果が表示の制限値より多い場合は、Administration Console にメッセージが表示されます。表示の制限値を増やすとパフォーマンスに影響を与える可能性があります。検索結果を無制限に表示するには、表示の制限値を 0 に設定してください。

同期の待機期間

com.sun.tta.confmgr.ArraySyncPeriod コンテキストパラメータは、Administration Console をセカンダリサーバーから実行しており、SGD データストアのオブジェクトを作成または編集する場合にのみ使用されます。このパラメータを使用すると、Administration Console が処理を続行する前に、変更がアレイ間でコピーされるのを待機する時間をミリ秒単位で設定できます。デフォルト値は 250 です。Administration Console は、この設定値の 2 倍、つまりデフォルトでは 0.5 秒待機してから、処理を続行します。

LDAP データの検索と表示

com.sun.tta.confmgr.LdapSearchTimeLimit コンテキストパラメータを使用すると、LDAP ディレクトリの検索に許容する最大の時間をミリ秒単位で設定できます。デフォルト値は 0 で、検索時間に制限がないことを意味します。特に低速な LDAP ディレクトリサーバーを使用している場合のみ、このコンテキストパラメータを変更してください。

次のコンテキストパラメータは、Administration Console で LDAP データの表示を絞り込むために使用します (「リポジトリ」リストで「ローカル + LDAP」を選択した場合)。

  • ナビゲーションツリーによって使用されるフィルタ。これらは、次のコンテキストパラメータです。

    • com.sun.tta.confmgr.LdapContainerFilter

    • com.sun.tta.confmgr.LdapUserFilter

    • com.sun.tta.confmgr.LdapGroupFilter

  • LDAP ディレクトリを検索するときに使用されるフィルタ。これらは、次のコンテキストパラメータです。

    • com.sun.tta.confmgr.LdapContainerSearchFilter

    • com.sun.tta.confmgr.LdapUserSearchFilter

    • com.sun.tta.confmgr.LdapGroupSearchFilter

  • ユーザープロファイルの「割り当て済みのアプリケーション」タブの LDAP 割り当てをロードするときに使用されるフィルタ。これは、com.sun.tta.confmgr.LdapMemberFilter コンテキストパラメータです。

これらのコンテキストパラメータには、Administration Console が何を LDAP コンテナ、ユーザー、およびグループとして認識するかの定義が入っています。パフォーマンスを向上させるためや、LDAP ディレクトリで使用されているものと一致するようにこれらの LDAP オブジェクトタイプの定義を変更する場合に、これらのフィルタを変更することもできます。一貫性がなくなるのを防ぐため、ナビゲーションツリーのフィルタを変更した場合は、LDAP 検索のフィルタも変更する必要があります。

セッションのタイムアウト

session-timeout 設定は、Administration Console でアクティビティーのない、つまり HTTP 要求のない時間がどのくらい継続するとユーザーがログアウトされるかを定義します。操作されていない Administration Console セッションが無制限に開いたままにならないように、デフォルトの設定値は 30 分になっています。



注 - session-timeout 設定は、アクティブでないユーザーセッションのタイムアウト属性 tarantella-config-array-webtopsessionidletimeout とは別個のものです。



Administration Console へのアクセスをセキュリティー保護する

Administration Console は Web アプリケーションであるため、どのクライアントデバイスにアクセスを許可するかを制御することができます。そのためには、たとえば、Apache <Location> 指令を使用するように SGD Web サーバーを設定します。次に例を示します。

<Location /sgdadmin>
   Order Deny,Allow
   Deny from all
   Allow from 129.156.4.240
</Location> 

この例では、IP アドレス 129.156.4.240 を持つクライアントデバイスだけが、SGD Web サーバーの /sgdadmin ディレクトリへのアクセスを許可されます。/sgdadmin ディレクトリには Administration Console のホームページが入っています。

<Location> 指令の設定方法の詳細については、Apache documentationを参照してください。


監視

この節では、SGD サーバーに関する問題の診断および解決に利用するために SGD ログを設定する方法について説明します。Administration Console を使用してユーザーセッションとアプリケーションセッションの監視および制御を行う方法についても説明します。

この節の内容は、次のとおりです。

セッション

この節では、SGD でのユーザーセッションとアプリケーションセッションの違いについて説明します。Administration Console を使用してユーザーセッションとアプリケーションセッションの監視および制御を行う方法についても説明します。

この節の内容は、次のとおりです。

ユーザーセッション

ユーザーセッションは、ユーザーが SGD にログインした時点で始まり、ユーザーが SGD からログアウトした時点で終わります。ユーザーセッションは、ユーザーがログインした SGD サーバーによってホストされます。ユーザーが入力したユーザー名とパスワードが、ユーザーのタイプを決定します。ユーザー認証の詳細については、第 2 章 を参照してください。

すでにユーザーセッションが開かれている場合にユーザーがログインすると、ユーザーセッションは新しい SGD サーバーに転送され、古いセッションは終了します。これは、「セッションの移動」または「セッションの乗っ取り」と呼ばれることがあります。

ユーザーセッションには、「標準」セッションまたは「セキュアセッション」を使用できます。セキュアセッションが使用可能なのは、SGD セキュリティーサービスが有効になっている場合だけです。詳細については、クライアントデバイスと SGD サーバー間の接続の保護を参照してください。

Administration Console では、次の手順でユーザーセッションを一覧表示できます。

  • ナビゲーションビューの「セッション」タブには、アレイ内のすべての SGD サーバーで実行されているすべてのユーザーセッションが表示されます。

  • SGD サーバーの「ユーザーセッション」タブには、その SGD サーバーでホストされているすべてのユーザーセッションが表示されます。

  • ユーザープロファイルの「ユーザーセッション」タブには、そのユーザープロファイルに関連付けられているすべてのユーザーセッションが表示されます。

「セッション」タブと「ユーザーセッション」タブでは、ユーザーセッションを選択して終了させることができます。「ユーザーセッション」タブでは、ユーザーセッションの詳細を表示することができます。たとえば、クライアントデバイスに関して SGD Client で検出された情報などです。

コマンド行からユーザーセッションを一覧表示したり終了したりするには、tarantella webtopsession コマンドを使用します。

アイドル状態のユーザーセッションのタイムアウト

アクティブでないユーザーセッションのアイドルタイムアウト時間を設定できます。SGD Client と SGD サーバーの間の AIP 接続で指定された期間アクティビティーが何も行われない場合、ユーザーセッションは中断されます。

次のデバイスでのアクティビティーはアイドルタイムアウト時間に影響を与えません。

  • シリアルポート

  • スマートカード

  • クライアントデバイス

  • 印刷

  • オーディオ

アイドルタイムアウト属性を指定するには、次のコマンドを使用します。


$ tarantella config edit \
--tarantella-config-array-webtopsessionidletimeout secs

ここで、secs はタイムアウト値 (単位は秒) です。0 に設定すると、アイドル状態のユーザーセッションのタイムアウト機能はオフになります。これは、デフォルト設定です。

アプリケーションセッション

アプリケーションセッションは、ユーザーがアプリケーションを起動した時点で始まり、アプリケーションを終了した時点で終わります。各アプリケーションセッションは、SGD を使って実行中のアプリケーションの 1 つに、それぞれ対応しています。

アプリケーションセッションは、アレイ内の SGD サーバーのいずれでもホストできます。ユーザーがログインしたのと同じ SGD サーバーではない場合もあります。アレイ を参照してください。

各アプリケーションセッションには、対応するプロトコルエンジンプロセスがあります。プロトコルエンジンは、クライアントデバイスとアプリケーションサーバーの間の通信を処理します。さらに、プロトコルエンジンは、アプリケーションで使われているディスプレイプロトコルを、クライアントデバイス上で実行中の SGD Client が認識する AIP に変換します。

アプリケーションセッションの負荷分散を使って、プロトコルエンジンの負荷を、アレイ内の SGD サーバー間で分散させることができます。詳細については、アプリケーションセッションの負荷分散を参照してください。

アプリケーションの中には、表示されていなくても実行し続けるように設定されるものもあります。それらは「再開可能」なアプリケーションと呼ばれます。

各アプリケーションオブジェクトには「アプリケーションの再開機能」属性があり、これによってアプリケーションを再開できるかどうかが決定されます。各アプリケーションは、次に示す「アプリケーションの再開機能」設定のいずれかを持ちます。


設定内容 説明
使用しない アプリケーションは、ユーザーが SGD からログアウトするときに終了します。再開可能でないアプリケーションを中断または再開することはできません。
ユーザーセッション中 アプリケーションは、ユーザーが SGD からログアウトするまで実行し続けます。ユーザーはログインしている間、それらのアプリケーションを中断および再開できます。
一般 アプリケーションは、ユーザーが SGD からログアウトしたあとも、実行し続けます。再度ログインした際に、「再開」ボタンをクリックすると、実行中のアプリケーションが再度表示されます。

アプリケーションが再開可能な場合、タイムアウトで指定されている一定期間のみ再開できます。SGD Client が予期せず終了した場合は、設定されているタイムアウトに 20 分を加えた値がタイムアウト期間になります。

再開可能なアプリケーションは、次の理由で役立ちます。

  • 起動に時間がかかるアプリケーションを、ユーザーが SGD からログアウトしたあとも実行したままにしておくことができる

  • モバイルユーザーが、移動中にアプリケーションを実行したままにすることができる

  • ブラウザなどがクラッシュした場合に、ユーザーが容易に復旧できる

Administration Console では、次の手順でアプリケーションセッションを一覧表示できます。

  • SGD サーバーの「アプリケーションセッション」タブには、そのサーバーでホストされているすべてのアプリケーションセッションが表示されます。

  • ユーザープロファイルの「アプリケーションセッション」タブには、そのユーザープロファイルに関連付けられているすべてのアプリケーションセッションが表示されます。

  • アプリケーションサーバーの「アプリケーションセッション」タブには、そのアプリケーションサーバーで実行されているすべてのアプリケーションが表示されます。

「アプリケーションセッション」タブでは、各アプリケーションセッションの詳細を表示できます。また、アプリケーションセッションを終了したりシャドウィングしたりすることもできます。セッションをシャドウィングすると、管理者とユーザーが同じアプリケーションを同時に使って対話することができます。

アプリケーションセッションのシャドウィングの詳細については、ユーザーの問題を解決するためのシャドウイングの使用 を参照してください。



注 - シャドウィングできるのは、Windows アプリケーションと X アプリケーションだけです。アプリケーションセッションを中断してはいけません。



コマンド行からユーザーセッションを一覧表示したり終了したりするには、tarantella emulatorsession コマンドを使用します。

匿名ユーザーと共有ユーザー

次のように、特殊な場合が 2 つあります。

これらのユーザーを区別するために、ゲストユーザーと匿名ユーザーにはログイン時に SGD によって一時的なユーザー識別情報が割り当てられます。これは次の影響を与えます。

  • ユーザーが SGD に複数回ログインするとユーザーセッションが転送されません

  • アプリケーションの「アプリケーションの再開機能」設定にかかわらず、ユーザーセッションが終了するとすぐにアプリケーションセッションが終了します

  • ユーザーがログアウトしない場合は、サーバーのリソースが消費されます。

ログフィルタを使用した SGD サーバーのトラブルシューティング

SGD の初回インストール時に、デフォルトのログフィルタに SGD サーバーのエラーがすべて記録されます。問題解決などのため、より詳細な情報が必要な場合は、追加のログフィルタを設定できます。

追加のログフィルタは次の方法で設定できます。

各ログフィルタの形式は次のとおりです。

component/subcomponent/severity:destination

フィルタの各部分のオプション、およびログ出力の表示方法については、以降の節で説明します。



注 - ログフィルタにより、大量のデータが生成される可能性があります。フィルタは可能なかぎり具体的に設定し、不要になったら削除することをお勧めします。



コンポーネントとサブコンポーネントの選択

コンポーネントおよびサブコンポーネントを選択することで、SGD サーバーから記録したい情報の分野を選択できます。

次の表に、使用可能なコンポーネントとサブコンポーネントの組み合わせ、および各組み合わせで得られる情報の種類について説明します。


コンポーネントとサブコンポーネント 提供される情報
audit/glue SGD サーバー設定またはローカルリポジトリ設定に加えた変更および変更の実行者に関する監査。

たとえば、これを使用して、ユーザープロファイルオブジェクトを変更したユーザーを確認できます。

audit/license SGD サーバーのアレイ全体にわたるライセンス使用状況。

たとえば、これを使用して、ライセンスの使用状況が記録されない理由を確認できます。

audit/session ユーザーセッションおよびアプリケーションセッションの開始と停止。

たとえば、これを使用して、ユーザーによるアプリケーションセッションの実行期間を確認できます。

cdm/audit クライアントドライブマッピング (CDM) のための SGD ユーザーの認証。

たとえば、これを使用して、ユーザーの資格情報が原因で CDM が失敗しているかどうかを確認できます。

cdm/server CDM サービスに関する情報。

たとえば、これを使用して、クライアント接続エラーが原因で CDM が失敗しているかどうかを確認できます。

common/config アレイ全体で SGD サーバー設定を格納およびコピーする方法。

たとえば、これを使用して、グローバル設定の設定変更が SGD サーバーに適用されない理由を確認できます。

metrics/glue メモリーおよびタイミング。

たとえば、これを使用して、SGD コマンドの実行に要した時間を確認できます。

metrics/soap Tomcat の SOAP プロキシの SOAP コンポーネント。

たとえば、これを使用して、SOAP 要求が完了するまでにかかった時間を追跡できます。

server/ad Active Directory 認証。

たとえば、これを使用して、Active Directory のユーザーがログインできない理由を確認できます。

server/billing SGD 課金処理サービス。

たとえば、これを使用して、課金処理データが失われた理由を調べることができます。

server/common SGD の一般情報。

たとえば、これを使用して、DNS エラーの問題をトラブルシューティングできます。

server/config SGD サーバー設定への変更。

たとえば、これを使用して、SGD サーバー設定への変更をログに記録する、または設定が壊れているかどうかを確認することができます。

server/csh SGD クライアントセッションハンドラ。

たとえば、これを使用して、ユーザーがアプリケーションセッションを再起動できない理由を確認できます。

server/deviceservice アクセス可能なデバイスデータへのユーザーのマッピング。

たとえば、これを使用して、ユーザーがクライアントドライブにアクセスできない理由を確認できます。

server/diskds ローカルリポジトリに関する情報。

たとえば、これを使用して、破壊されているオブジェクトやローカルリポジトリ内の不一致に関する情報を取得できます。

server/glue SGD サーバー間の通信に使用されるプロトコル。

たとえば、これを使用して、SGD サーバーが通信できない理由を確認できます。

server/install インストールおよびアップグレード。

たとえば、これを使用して、インストールに関する問題を調査できます。

server/kerberos Windows Kerberos 認証。

たとえば、これを使用して、Active Directory のユーザーがログインできない理由を確認できます。

server/launch アプリケーションの起動または再開。

たとえば、これを使用して、ユーザーがアプリケーションを起動できない理由を確認できます。

server/ldap LDAP サーバーへの接続。

たとえば、これを使用して、LDAP ユーザーがログインできない理由を確認できます。

server/loadbalancing ユーザーセッションおよびアプリケーションの負荷分散。

たとえば、これを使用して、アプリケーションセッションをホストする SGD サーバーが選択されていない理由を確認できます。

server/logging ログ。

たとえば、これを使用して、ログメッセージがファイルに書き込まれない理由を確認できます。

server/login SGD にログインします。

たとえば、これを使用して、ユーザーおよび使用するユーザープロファイルを認証した認証機構を確認できます。

server/mupp SGD MUPP (MUltiplePlexing Protocol) プロトコル。

サポートから依頼された場合にのみ、このフィルタを使用する。

server/printing SGD 印刷サービス。

たとえば、これを使用して、印刷ジョブが失敗する理由を確認できます。

server/replication アレイ内の SGD サーバー間でのデータコピー。

たとえば、これを使用して、アレイメンバー間でデータがコピーされない理由を確認できます。

server/securid SecurID RSA Authentication Manager への接続。

たとえば、これを使用して、SecurID 認証が機能しない理由を確認できます。

server/security セキュアな SSL ベースの接続。

たとえば、これを使用して、SSL デーモンが実行されない理由を確認できます。

server/server SGD サーバーコンポーネント。

たとえば、これを使用して、ほかの場所には記録されない Java™ 実行時例外などの、SGD サーバーの失敗をトラブルシューティングできます。

server/services 内部の SGD サーバーサービス。

たとえば、これを使用して、サービスが失敗する理由を確認できます。

server/session ユーザーセッション。

たとえば、これを使用して、セッションが中断に失敗する理由を確認できます。

server/soap SOAP Bean インタフェース。

たとえば、これを使用して、SOAP Bean の問題を診断できます。

server/soapcommands SOAP 要求。

たとえば、これを使用して、受信した SOAP 要求をログに記録できます。

server/tier3loadbalancing アプリケーションサーバーの負荷分散。

たとえば、これを使用して、アプリケーションを起動するアプリケーションサーバーが選択されていない理由を確認できます。

server/tokencache 認証トークンのキャッシュ。

たとえば、これを使用して、あるユーザーに認証トークンが作成されない理由を確認できます。

server/tscal Windows 以外のクライアント用の Windows ターミナルサービス Client Access License (CAL)。

たとえば、これを使用して、Windows 以外のクライアントが CAL を保持しない理由を確認できます。

server/webtop Webtop コンテンツ (Directory Services Integration を使用している場合)。

たとえば、これを使用して、アプリケーションがユーザーの Webtop に表示されない理由を確認できます。


重要度の選択

各ログフィルタについて、次の重要度レベルのいずれかを選択できます。


重要度 説明
fatalerror 致命的エラーに関する情報をログに記録します。致命的エラーが発生すると、SGD サーバーは実行を停止します。SGD の初回インストール時には、すべての致命的エラーがデフォルトでログに記録されます。
error 発生したすべてのエラー情報をログに記録します。SGD の初回インストール時には、すべてのエラーがデフォルトでログに記録されます。
warningerror システムリソースの減少などの、発生したすべての警告に関する情報をログに記録します。SGD の初回インストール時には、すべての警告がデフォルトでログに記録されます。
info 情報ログ。バグの解決や識別に役立ちます。
moreinfo 詳細な情報ログ。
auditinfo SGD サーバー設定の変更など、選択したイベントのログを監査目的で記録します。詳細については、次を参照してください, ログフィルタを使用した監査.

重要度 fatalerror の場合に、生成される情報がもっとも少なくなります。重要度 moreinfo の場合に、生成される情報量がもっとも多くなります。

重要度レベルの選択は、累積的ではありません。たとえば、info を選択しても、warningerror または fatalerror ログメッセージは表示されません。

複数の重要度レベルをログに記録する場合は、ワイルドカードを使用します。

ワイルドカードの使用

ワイルドカード (*) を使用して、複数のコンポーネント、サブコンポーネント、および重要度に一致させることができます。

たとえば、すべての警告、エラー、および致命的エラーメッセージを印刷用としてログに記録する場合、server/printing/*error ログフィルタを使用できます。



注 - コマンド行でワイルドカードを使用する場合は、フィルタを引用符で囲んで、シェルにより展開されないようにする必要があります。



出力先の選択

ログの出力先として、次のいずれかを指定できます。

  • ログファイル

  • ログハンドラ

これらの出力先について以降のセクションで説明します。

ログファイルの使用

ログファイルに出力する場合、次の種類のファイルに出力が可能です。

  • filename.log

    SGD により、このログ出力は読みやすく書式設定されます。

    tarantella query errlog コマンドの実行には、この形式が必須です。このコマンドは、名前の末尾が error.log であるログファイルだけを検索します。

  • filename.jsl

    SGD により、このログ出力は自動構文解析および検索に合わせて書式設定されます。

    tarantella query audit コマンドの実行には、この形式が必須です。

ファイルの形式は、出力先ファイルのファイル拡張子により制御されます。

ファイル名に %%PID%% プレースホルダーを含めることで、プロセス ID ごとに別個のログファイルを作成することもできます。

ログファイルは、/opt/tarantella/var/log ディレクトリに出力されます。ログファイルの位置を変更することはできませんが、シンボリックリンクを使用してログを別の場所にリダイレクトできます。また、syslog ログハンドラを使用することもできます。詳細は、ログハンドラの使用 を参照してください。

ログハンドラの使用

ログハンドラは、ログメッセージの出力先として使用される JavaBeanstrademark コンポーネントです。ログハンドラを指定する場合は、その完全な名前を使用する必要があります。SGD では、次のログハンドラが提供されます。

  • ConsoleSink - ConsoleSink ログハンドラは、ログメッセージを読みやすい書式で標準エラーに書き出します。このログハンドラは、デフォルトで有効で、すべてのエラーをログに記録します。

    このログハンドラの完全な名前を、次に示します。

    .../_beans/com.sco.tta.server.log.ConsoleSink

  • SyslogSink - SyslogSink ログハンドラは、ログメッセージを UNIX または Linux プラットフォームの syslog 機能に書き出します。

    このログハンドラの完全な名前を、次に示します。

    .../_beans/com.sco.tta.server.log.SyslogSink

ログフィルタの使用例

次に、一般的に使用されるログフィルタの例を示します。

  • ユーザーログインをデバッグする:

    server/login/*:login%%PID%%.log
    server/login/*:login%%PID%%.jsl

  • CDM の問題を解決する:

    cdm/*/*:cdm%%PID%%.log
    cdm/*/*:cdm%%PID%%.jsl
    server/deviceservice/*:cdm%%PID%%.log
    server/deviceservice/*:cdm%%PID%%.jsl

  • 印刷の問題を解決する:

    server/printing/*:print%%PID%%.log
    server/printing/*:print%%PID%%.jsl

  • サーバーパフォーマンスのタイミング測定を取得する:

    metrics/*/*info:metrics.log
    metrics/*/*info:metrics.jsl

  • すべての警告、エラー、および致命的エラーを syslog に送信する:

    */*/*error:.../_beans/com.sco.tta.server.log.SyslogSink

ログ出力の表示

ログ出力を表示するには、次のいずれかを実行します。

  • .log ファイルをビューアまたはテキストエディタで開きます。

  • tarantella query コマンドを使用します。

tarantella query コマンドを使用する場合は、次のコマンドオプションを使用します。

  • tarantella query errlog - 特定の SGD サーバーコンポーネントのエラーおよび致命的エラーだけを表示する場合

  • tarantella query audit - 人物、アプリケーション、またはアプリケーションサーバーに関するメッセージのログをすべて検索する場合



注 - これらのコマンドを使用してログ出力を表示できるのは、ログがアーカイブされるまでです。アーカイブの設定は SGD のインストール時に行いますが、tarantella setup コマンドを実行することでいつでも設定を変更できます。



ログフィルタを使用した監査

SGD では、ログフィルタを設定して次のシステムイベントを監査できます。

これらのイベントを監査するには、*/*/*auditinfo ログフィルタを設定する必要があります。

任意の標準出力先を使用できますが、監査情報をコマンド行から表示するためには、.jsl ファイルに出力する必要があります。

ログフィルタの設定についての詳細は、ログフィルタを使用した SGD サーバーのトラブルシューティング を参照してください。



注 - ログの出力は、SGD サーバーが実際に実行されている場合のみ作成されます。SGD サーバーが停止している場合、UNIX システムの root ユーザーのみが監査可能なイベントを実行できます。



各イベントに関する次の情報が、ログフィルタによって記録されます。

監査ログ情報の表示

ログ出力は、標準の方法を使用して表示できます。ただし、次のコマンドがもっとも役立ちます。


# tarantella query audit --format text|csv|xml --filter "filter"

text 形式を選択した場合、SGD は画面上で読みやすい形式のログを出力しますが、これには記録されたすべての詳細情報は表示されません。csv 形式を使用すると、記録された詳細情報はすべて表示されますが、これはファイルに出力する場合のみに適しています。

"filter" は、RFC2254-compliant LDAP 検索フィルタです。このコマンドで、ログファイルのログフィールドから該当するエントリを検索して表示します。次の表に、監査の際に特に役立つログフィールドを示します。


ログフィールド 説明
log-category log-category は監査を行う場合は常に *auditinfo ですが、任意の標準ログフィルタのコンポーネント/サブコンポーネント/重要度の設定にすることができます。
log-date イベント発生時のシステム日時。

形式は yyyy/MM/dd HH:mm:ss.SSS です。

log-event イベントの名前。
log-ip-address イベントに関連付けられているクライアントまたはサーバーの IP アドレス。
log-keyword 監査可能なイベントのキーワード ID。
log-localhost イベントが発生した SGD サーバーのピア DNS 名。
log-pid イベントのプロセス ID。
log-security-type 接続に使用されているセキュリティーのタイプ (std または ssl)。
log-systime イベント発生時のシステム時刻を表す UTC (Coordinated Universal Time) 時間 (ミリ秒単位)。
log-tfn-name イベントに関連付けられているオブジェクトの完全な名前。

たとえば、アプリケーションセッションを起動すると、ユーザー、アプリケーション、およびアプリケーションサーバーの名前が記録される場合があります。




注 - すべてのログフィールドのリストは、/opt/tarantella/var/serverresources/schema/log.at.conf スキーマファイルで参照できます。



すべての log-keyword と該当する log-event を次の表に示し、イベントについて説明します。


Log-keyword Log-event 説明
createFailure createFailure ユーザーがローカルリポジトリのオブジェクトの作成に失敗しました。
createSuccess createSuccess ユーザーがローカルリポジトリのオブジェクトを作成しました。
deleteFailure deleteFailure ユーザーがローカルリポジトリのオブジェクトの削除に失敗しました。
deleteSuccess deleteSuccess ユーザーがローカルリポジトリのオブジェクトを削除しました。
loginFailure loginResultReconnect SGD サーバーからクライアントに対して、異なるポートへの再接続が要求されました。
loginFailure loginResultFailed 有効にされている認証機構のいずれによっても、ユーザーが認証されませんでした。
loginFailure loginResultRejected ログインフィルタによってユーザーのログインが拒否されました。これには、特定のサーバーで現在ログインが許可されていない、ユーザーのログインが現在許可されていない、などの原因が考えられます。
loginFailure loginResultDisabled 現在、SGD サーバーは接続を受け付けていません。
loginFailure loginResultNoAmbig SGD サーバーであいまいなユーザーのログインがサポートされていないため、あいまいなログインが失敗しました。
loginFailure loginResultAmbiguous ユーザーが十分な情報を指定したため、あいまいなログインが失敗しました。
loginFailure loginResultAnonymous SDG サーバーで匿名ログインがサポートされていないため、匿名ログインが失敗しました。
loginFailure loginResultNoSecurity 標準ポートで接続が確立されたため、セキュア接続を要求するユーザーのログインが失敗しました。
loginFailure loginResultUnresolveable SGD サーバーでユーザーを解決できなかったため、ログインが失敗しました。
loginFailure loginResultUnknown SGD サーバーで予測外のログイン結果を処理できなかったため、ログインが失敗しました。
loginSuccess webtopSessionStartedDetails ユーザーのユーザーセッションが開始されました。
logout webtopSessionEndedDetails ユーザーのユーザーセッションが停止されました。
modifyFailure modifyFailure ユーザーがローカルリポジトリのオブジェクトの変更、グローバル設定の変更、または SGD サーバーの設定の変更に失敗しました。
modifySuccess modifySuccess ユーザーがローカルリポジトリのオブジェクトの変更、グローバル設定の変更、または SGD サーバーの設定の変更を行いました。
renameFailure renameFailure ユーザーがローカルリポジトリのオブジェクトの名前変更に失敗しました。
renameSuccess renameSuccess ユーザーがローカルリポジトリのオブジェクトの名前を変更しました。
serverStart serverStart SGD サーバーが起動しました。
serverStop serverStop SGD サーバーが停止しました。
sessionEnded sessionEndedDetails ユーザーのアプリケーションセッションが停止されました。
sessionStarted sessionStartedDetails ユーザーのアプリケーションセッションが開始されました。
sslStart securitySSLStart SGD セキュリティー (SSL) サービスが開始しました。
sslStop securitySSLStop SGD セキュリティー (SSL) サービスが停止しました。

ログフィルタを使用した監査の例

失敗したログインを検索するには、次のフィルタを使用します。

--filter "(&(log-category=*auditinfo)(log-keyword=loginFailure))"

SGD サーバーの設定に対する、管理者 Bill Orange による変更を検索するには、次のフィルタを使用します。

--filter "(&(log-category=*auditinfo)(log-keyword=modifySuccess)(log-tfn-name=.../ens/o=Indigo Insurance/ou=IT/cn=Bill Orange))"


ライセンスと SGD

SGD には、「評価モード」と「フルライセンスモード」の 2 種類のライセンスモードがあります。


ライセンスモード 説明
評価モード
  • ライセンスキーがインストールされていない場合に適用されます。

  • SGD を 30 日間評価できます。

  • アレイのサイズは、2 つの SGD サーバーに制限されます。

  • ログイン可能またはアプリケーションを実行可能なユーザーの数は、5 人に制限されます。

フルライセンスモード
  • ライセンスキーがインストールされている場合に適用されます。

  • アレイのサイズに制限はありません。

  • ログイン可能またはアプリケーションを実行可能なユーザーの数は、インストールされたライセンスキーで決まります。


SGD の評価期間に、ブラウザを使って SGD にログインすると、評価期間の残りの日数が表示されます。

30 日間の評価期間が満了したあと、ユーザーが Webtop にログインすることや、アプリケーションを起動または再開することはできなくなります。SGD を引き続き使用するには、ライセンスキーを取得してインストールする必要があります。

ライセンスキーの追加は、Administration Console の「グローバル設定」 → 「ライセンス」タブで行います。また、tarantella license add コマンドを使用することもできます。

この節の内容は、次のとおりです。

ライセンスキーとライセンス

ライセンスキーをインストールすると、ロックされているソフトウェア機能が解除されます。ライセンスには、次の種類のいずれかです。

次の表に、使用可能なライセンスの種類とそのベース、およびそのライセンスで利用可能な機能を示します。


ライセンスの種類 ベース ソフトウェア機能
基本コンポーネント ユーザー 次の基本機能を使用できます。
  • ログイン。

  • LDAP ディレクトリサーバーに対するユーザーの認証。

  • SOCKS v5 プロキシサーバーのサポート。

  • HTTP およびセキュア SSL プロキシサーバーのサポート。

  • ファイアウォールを経由した通信。

  • セキュア接続の使用。

  • Webtop、アプリケーションの起動、およびセッションの管理。

  • アレイのサポート。

Windows Connectivity ユーザー Windows アプリケーションの実行。
UNIX Connectivity ユーザー UNIX および Linux アプリケーションの実行。
AS/400 Connectivity ユーザー 5250 アプリケーションの実行。
Mainframe Connectivity ユーザー 3270 アプリケーションの実行。
Advanced Load Management アレイ 真の CPU またはメモリー負荷に基づく、アプリケーションサーバーの負荷分散。

ユーザーベースのライセンス

ユーザーベースのライセンスは、同時実行ユーザーベースで、ソフトウェアによって有効にされます。ユーザーがソフトウェアコンポーネントを使用するとすぐに、ライセンスがユーザーに割り当てられます。

たとえば、ユーザーが SGD にログインすると、基本コンポーネントライセンスが割り当てられます。ユーザーが Windows アプリケーションを実行すると、Windows Connectivity ライセンスが割り当てられます。コンポーネントの使用を停止すると、ライセンスが解放されます。

1 人のユーザーが、1 種類のライセンスを複数使用しているものとカウントされることはありません。たとえば、ユーザーがログインして 4 つの UNIX アプリケーションを実行している場合、そのユーザーは基本コンポーネントライセンスを 1 つ、および UNIX Connectivity ライセンスを 1 つ使用しているとカウントされます。

ユーザーベースのライセンスについては、次の点に留意してください。

  • 各ゲストユーザーと匿名ユーザーは、それぞれ別のユーザーとしてカウントされます。ゲストユーザー用の共有アカウントの使用 および 匿名ユーザーの認証 を参照してください。

  • すべての基本コンポーネントライセンスが割り当て済みになると、それ以上のユーザーが SGD にログインできなくなります。

  • ユーザーがアプリケーションを中断した場合、SGD にログインしていなくても、そのユーザーはコネクティビティーコンポーネントを引き続き使用し、ライセンスを保持しているとカウントされます。

  • ユーザーが、常に再開可能に設定されているアプリケーションを閉じずに SGD をログアウトした場合、アプリケーションはタイムアウトするまで実行し続け、コネクティビティーコンポーネントを使用し続けます。デフォルトのタイムアウトの長さは 8 日間です。

  • ユーザーが SGD にログインしても、アプリケーションを一切実行できない場合があります。これは、基本コンポーネントライセンスは使用可能であるが、すべてのコネクティビティーライセンスが、ログインしていないがアプリケーションセッションを中断しているユーザーに使用されているためです。

ライセンスの管理

SGD は、ユーザーがソフトウェアコンポーネントを使用する際に、ライセンスの割り当ておよび解除を自動的に行います。SGD 管理者は、ユーザーの SGD セッションおよびアプリケーションセッションを終了させることはできても、ライセンスの割り当ておよび解除を手動で実行することはできません。

SGD ログファイルには、すべてのライセンス使用状況が経時的に記録されます。管理者 は tarantella license query コマンドを使用して、現在と過去のライセンス使用状況を表示できます。

Microsoft Windows ターミナルサービスのライセンス

SGD には、Microsoft Windows ターミナルサービスのライセンスは含まれていません。Microsoft オペレーティングシステム製品で提供されるターミナルサーバー機能にアクセスするには、該当する製品を使用するための追加ライセンスを購入する必要があります。使用している Microsoft オペレーティングシステム製品のライセンス契約書を参照して、入手する必要のあるライセンスを確認してください。

ターミナルサービスのライセンス管理は、クライアントアクセスライセンス (CAL) を使用して行います。CAL は、クライアントに Windows ターミナルサーバーへのアクセスを許可するライセンスです。ライセンスモードに応じて、クライアントは「ユーザー」、「デバイス」、またはその両方の組み合わせになります。

Microsoft Windows ターミナルサービスのクライアントライセンス管理は、クライアントプラットフォームによって次のように異なります。

CAL をコマンド行から管理する

tarantella tscal コマンドを使用して、Windows 以外のクライアントデバイスの Microsoft Windows ターミナルサービス CAL を次のように管理できます。

  • Windows 以外のクライアントに現在予約されているターミナルサービス CAL の一覧を表示するには、次のコマンドを入力します。


    $ tarantella tscal list
    

  • 別の Windows 以外のクライアントで使用するためにターミナルサービス CAL を解放するには、次のコマンドを入力します。


    $ tarantella tscal free
    

  • 解放されているすべてのターミナルサービス CAL を Windows ライセンスサーバーに戻すには、次のコマンドを入力します。


    $ tarantella tscal return --free
    


SGD サーバーの証明書ストア

各 SGD サーバーには、CA 証明書トラストストアとクライアント証明書ストアという 2 つの証明書ストアがあります。

CA 証明書トラストストア

各 SGD サーバーには、独自の CA 証明書トラストストアがあります。これは /opt/tarantella/bin/jre/lib/security/cacerts ファイルです。

CA 証明書トラストストアには、SGD サーバーで信頼されている CA 証明書が格納されます。

/opt/tarantella/etc/data/cacerts.txt ファイルには、SGD の最初のインストール時に CA 証明書トラストストアにあるすべての CA 証明書の、X.500 識別名 (DN) と MD5 署名が入っています。これらは、SGD がデフォルトでサポートしている CA です。ほかの CA のサポートを追加するには、CA 証明書をトラストストアにインポートします。

次に挙げる状況では、CA 証明書のインポートが必要になることがあります。

インポートする必要がある証明書は次のとおりです。

tarantella security customca コマンドを使用して CA 証明書または CA 証明書チェーンをインストールすると、CA 証明書は CA 証明書トラストストアにもインポートされます。これが行われるのは、このコマンドを実行した SGD サーバー上だけです。

CA 証明書を手動でインポートするには、keytool アプリケーションを使用します。keytool アプリケーションの使用方法の詳細については、「JDK Tools and Utilities」を参照してください。SGD ホストの /opt/tarantella/var/tsp/ca.pem ファイルには、CA 証明書または証明書チェーンが格納されています。

CA 証明書チェーンをインポートする必要がある場合は、チェーン内の各証明書を個別にインポートしてください。

CA 証明書トラストストアのパスワードは changeit です。

procedure icon  CA 証明書または証明書チェーンを CA 証明書トラストストアにインポートする方法

  1. SGD ホストにスーパーユーザー (root) としてログインします。

  2. CA 証明書をインポートします。

    CA 証明書チェーンをインポートするには、チェーン内の各証明書を個別にインポートする必要があります。

    次のコマンドを使用します。


    # /opt/tarantella/bin/jre/bin/keytool -importcert \
    -keystore /opt/tarantella/bin/jre/lib/security/cacerts \
    -storepass changeit -file CA-certificate-path \
    -alias alias
    

    -alias オプションを使って、証明書を一意に識別します。

クライアント証明書ストア

各 SGD サーバーには、独自のクライアント証明書ストアがあります。これは /opt/tarantella/var/info/certs/sslkeystore ファイルです。

クライアント証明書ストアには、SGD サーバーが別のサーバーに接続する際に自身の識別に使用する、クライアント証明書が格納されます。

サーバーのクライアント証明書の作成とインストールには keytool アプリケーションを使用します。keytool アプリケーションの使用方法については、「JDK Tools and Utilities」を参照してください。

クライアント証明書ストアに対して証明書の追加または削除を行うときは、パスワードを入力する必要があります。クライアント証明書ストアのパスワードは SGD ごとに固有で、/opt/tarantella/var/info/key ファイル内にあります。-storepass および -keypass オプションの両方で、このパスワードを使用します。

procedure icon  SGD サーバーのクライアント証明書の CSR を作成する方法

  1. SGD ホストにスーパーユーザー (root) としてログインします。

  2. クライアント証明書のキーペアを生成します。


    # /opt/tarantella/bin/jre/bin/keytool -genkeypair \
    -keyalg rsa \
    -keystore /opt/tarantella/var/info/certs/sslkeystore \
    -storepass "$(cat /opt/tarantella/var/info/key)" \
    -alias alias \
    -keypass "$(cat /opt/tarantella/var/info/key)"
    

    -alias オプションを使って、キーペアを一意に識別します。

  3. クライアント証明書の CSR を生成します。


    # /opt/tarantella/bin/jre/bin/keytool -certreq \
    -keystore /opt/tarantella/var/info/certs/sslkeystore \
    -storepass "$(cat /opt/tarantella/var/info/key)" \
    -alias alias \
    -keypass "$(cat /opt/tarantella/var/info/key)" \
    -file CSR-path
    

    alias には、鍵ペアの生成時に使用したエイリアスを指定してください。エイリアスの大文字と小文字は区別されません。

procedure icon  SGD サーバーのクライアント証明書をインストールする方法

  1. SGD ホストにスーパーユーザー (root) としてログインします。

  2. クライアント証明書をインストールします。


    # /opt/tarantella/bin/jre/bin/keytool -importcert \
    -file certificate-path 
    -keystore /opt/tarantella/var/info/certs/sslkeystore \
    -storepass "$(cat /opt/tarantella/var/info/key)" \
    -alias alias \
    -keypass "$(cat /opt/tarantella/var/info/key)"
    

    クライアント証明書の CSR の生成時に使用したエイリアスを指定してください。エイリアスの大文字と小文字は区別されません。


SGD のインストール

この節では、SGD インストールに含まれているファイルについて説明します。SGD インストールのバックアップと復元についても説明します。

この節の内容は、次のとおりです。

SGD のインストールについて

SGD の標準のインストールディレクトリは、/opt/tarantella です。

SGD のインストール中に別のインストールディレクトリを指定することもできます。

インストールディレクトリをコマンド行から調べることができます。次の手順を実行します。

SGD のインストールディレクトリには、次のサブディレクトリが含まれています。

以降の節では、これらの各サブディレクトリに含まれている内容と、それらの使用目的について説明します。

SGD インストールのバックアップと復元も参照してください。

bin ディレクトリ

bin ディレクトリには、SGD を実行するのに必要なスクリプト、バイナリ、サーバー側 Java‘ テクノロジが格納されています。

etc ディレクトリ

etc ディレクトリには、SGD の動作や SGD を使って表示したアプリケーションの動作を制御する構成ファイルが格納されています。次の表に示すサブディレクトリが含まれています。


サブディレクトリ 目次
etc/data 構成ファイルは下記のとおりです。
  • 文字型アプリケーションオブジェクトの設定ファイル:

    • 属性マップ (attrmap.txt)

    • カラーマップ (colormap.txt)

  • 印刷設定ファイル:

    • ホスト名マップ (hostnamemap.txt)

    • プリンタドライバマップ (default.printerinfo.txt)

    • プリンタドライバからプリンタタイプへのマッピング (printertypes.txt)

    • プリンタからユーザーフレンドリな名前へのマッピング (printernamemap.txt)

  • RGB カラー名 (rgb.txt)

  • タイムゾーン設定ファイル

  • サポートされている CA 証明書 (cacerts.txt)

etc/data/keymaps キーボードマップファイル。
etc/fonts X Window System フォントと SGD にインストールされる追加フォント。
etc/pkg インストールされている SGD パッケージに関する情報 (バージョンの互換性や依存関係など)。
etc/templates etc/data ディレクトリと var/serverresources ディレクトリにインストールされた標準ファイルの完全なコピー。

var ディレクトリ

var ディレクトリには、Web サーバーによって使用されるファイルと、SGD サーバーによって他のアレイメンバーにコピーされるファイルがあります。var ディレクトリには数多くのサブディレクトリがありますが、そのうち主要なものを次の表に示します。


サブディレクトリ 目次
var/docroot SGD Web サーバーで使用する HTML ページ。
var/tsp サーバーのセキュリティー証明書、キー、および CA 証明書。
var/ens 組織階層内のオブジェクトを含むローカルリポジトリ。
var/log SGD サーバーのログファイル。
var/print 印刷待ち行列と先入れ先出し (FIFO)。
var/serverresources/expect SGD ログインスクリプト。
var/spool 印刷待ち行列に送信される途中のファイル。

webserver ディレクトリ

webserver ディレクトリには、SGD Web サーバー、Web サービス、および Webtop の実行に必要なスクリプト、バイナリ、およびサーバー側 Java テクノロジが格納されています。重要なサブディレクトリを次の表に示します。


サブディレクトリ 目次
apache SGD Web サーバーの設定と実行に必要なすべてのファイル。
tomcat Tomcat JSP およびサーブレットコンテナの設定と実行に必要となるすべてのファイル。
tomcat/5.0.28_axis1.2/webapps/axis SGD Web サービスの実行に必要なファイル。Webtop は、Web サービスを使用します。
tomcat/5.0.28_axis1.2/webapps/sgd SGD Client など、Webtop の実行に必要なファイル。
tomcat/5.0.28_axis1.2/shared/lib
tomcat/5.0.28_axis1.2/shared/classes

SGD インストールのバックアップと復元

この節では、SGD インストールをバックアップして、SGD のコンポーネントまたはインストール全体が損傷した場合に修復する方法について説明します。

このページの手順を実行する前に、SGD インストールのレイアウトについて把握しておくと役立ちます。SGD のインストールについてを参照してください。

この節の内容は、次のとおりです。

procedure icon  SGD インストールのフルバックアップを作成する方法

SGD インストールを復元したり、一部の SGD コンポーネントを個別に修復したりするには、フルバックアップが必要になります。

バックアップを作成しているときに、コマンド行ツールを実行したり、Administration Console を使用したりしないでください。バックアップを作成しているときは、SGD サーバーをシャットダウンすることをお勧めします。シャットダウンできない場合は、サーバーの負荷が少ないときにバックアップを実行してください。

  1. SGD ホストにスーパーユーザー (root) としてログオンします。

  2. SGD ログファイルをバックアップします。


    # tarantella archive
    

  3. アレイ内の各 SGD サーバーで、SGD インストールディレクトリ全体をバックアップします。

    SGD インストールディレクトリの詳細は、SGD のインストールについて を参照してください。

    SGD では、次の構成ファイルも使用されます。これらのファイルについては、使用しているファイルのうち、変更を加えたものだけをバックアップするだけでかまいません。

    • /etc/ttaprinter.conf ファイル - lpr のデフォルトが含まれています

    • /etc/sdace.txt および /var/ace/data ファイル - RSA SecurID 設定が含まれています

    • Web サーバーのパスワードファイル - SGD Web サーバーで使用するためにこれらのファイルを作成し、SGD インストールディレクトリの外部に保存している場合

損傷した SGD コンポーネントを復元する方法

損傷したインストールを復元するために、SGD を次のコンポーネントに分けることができます。

  • バイナリファイル、スクリプトファイル、およびテンプレートファイル

  • ログインスクリプト

  • サーバー設定

  • グローバル設定

  • ローカルリポジトリ

  • 自動ログアーカイブ

  • SGD 印刷

  • SGD Web サーバー、Web サービス、および Webtop

続く節では、これらの各コンポーネントをバックアップする方法について説明します。

バイナリファイル、スクリプトファイル、およびテンプレートファイル

バイナリファイル、スクリプトファイル、およびテンプレートファイルが変更されるのは、インストール、パッチ、またはカスタマイズ作業のときだけです。これらのファイルが変更されることはあまりありません。

これらのファイルは、バックアップまたは再インストールによって次のように復元できます。

  • バイナリファイルは、/opt/tarantella/bin/bin ディレクトリにあります

  • スクリプトファイルは、/opt/tarantella/bin/scripts ディレクトリにあります

  • テンプレートファイルは、/opt/tarantella/etc/templates ディレクトリにあります

ログインスクリプト

ログインスクリプトは、SGD とアプリケーションサーバーの間の対話 (たとえば、ユーザーのログイン) を制御するファイルです。ログインスクリプトを参照してください。

ログインスクリプトの復元方法は、カスタマイズしたログインスクリプトを使用しているかどうかに応じて異なります。

カスタマイズしたログインスクリプトを使用していない場合は、再インストール、バックアップ、または /opt/tarantella/etc/templates ディレクトリから復元できます。

カスタマイズしたログインスクリプトを使用している場合は、バックアップを使用して復元する必要があります。

ログインスクリプトは、/opt/tarantella/var/serverresources/expect ディレクトリにあります。

サーバー設定

サーバー設定とは、サーバー DNS 名やサーバー調整など、SGD サーバーのプロパティーのうち、アレイのほかの SGD サーバーと共有されないすべてのプロパティーのことです。

この設定は特定の SGD ホストに固有なので、そのホストから作成したバックアップから復元する必要があります。

サーバー固有の設定は、/opt/tarantella/var/serverconfig/local ディレクトリにあります。

SGD セキュリティーサービスを使用している場合は、次の内容も復元する必要があります。

  • /opt/tarantella/var/tsp

  • /opt/tarantella/var/info/certs

  • /opt/tarantella/var/info/key

グローバル設定

グローバル設定とは、他のアレイメンバーの名前など、アレイ内のすべての SGD サーバーに共通のプロパティーすべてのことです。

SGD サーバーのグローバル設定を復元するには、プライマリ SGD サーバーのバックアップから復元する必要があります。

グローバル設定は、/opt/tarantella/var/serverconfig/global ディレクトリにあります。

ローカルリポジトリ

ローカルリポジトリ (旧称 ENS (Enterprise Naming Scheme)) は、アレイ内のすべての SGD サーバーで共有されます。ローカルリポジトリは、ユーザー、アプリケーション、およびアプリケーションサーバーに関するすべての情報を含む組織階層になります。これらの情報は、非常に頻繁に変更されます。

ローカルリポジトリは、プライマリ SGD サーバーのバックアップから復元します。

ローカルリポジトリは、/opt/tarantella/var/ens ディレクトリにあります。

自動ログアーカイブ

デフォルトでは、毎週日曜日の午前 4 時に cron ジョブを使用して、ログファイルのアーカイブが作成されます。

root ユーザーの crontab が破壊したり、アーカイブが実行されなかったりした場合は、tarantella setup コマンドを使用してデフォルト設定を復元するか、アーカイブの実行日時を変更します。

ログファイルのアーカイブは、/opt/tarantella/var/log ディレクトリに作成されます。

SGD 印刷

SGD をインストールすると、SGD プリンタキューが設定されます。

プリンタキューが存在しない場合、次のいずれかの方法で復元できます。

プリンタキューは、/opt/tarantella/var/print ディレクトリにあります。

SGD Web サーバー、Web サービス、および Webtop

SGD Web サーバー、SGD Web サービス、および Webtop の設定は、特定の SGD ホストに固有なので、そのホストから作成したバックアップから復元する必要があります。

SGD Web サーバーの設定は、/opt/tarantella/webserver/apache/2.2.8_openssl-0.9.8g_jk1.2.25 ディレクトリにあります。Web サーバーのパスワードファイルがある場合は、他の場所に格納されていることがあります。

SGD Web サービスの設定は、/opt/tarantella/webserver/tomcat/5.0.28_axis1.2 ディレクトリにあります。

Webtop で使用するファイルは、/opt/tarantella/webserver/tomcat/5.0.28_axis1.2/webapps/sgd ディレクトリにあります。

procedure icon  SGD インストールを完全に復元する方法

損傷した SGD コンポーネントを復元できない場合、またはシステムがどの程度損傷しているかわからない場合は、SGD インストールを完全に復元する必要があります。

完全な復元を実行するには、フルバックアップが必要です。SGD インストールのバックアップ方法の詳細については、SGD インストールのフルバックアップを作成する方法 を参照してください。

SGD サーバーにログインしているユーザーがいないことと、中断しているアプリケーションセッションも含め、SGD サーバー上で実行されているアプリケーションセッションがないことを確認します。

  1. SGD ホストにスーパーユーザー (root) としてログオンします。

  2. SGD サーバーを停止します。

  3. SGD をアンインストールします。


    # tarantella uninstall --purge
    



    注 - これに失敗した場合、手動で SGD パッケージを削除しなければならないかもしれません。Linux プラットフォームでは rpm -e tta コマンド、Solaris OS プラットフォームでは pkgrm tta コマンドで削除してください。



  4. SGD インストールディレクトリを削除します。


    # rm -rf /opt/tarantella
    

  5. SGD とパッチ (適用されていた場合) を再インストールします。

    これにより、プリンタキュー、rc スクリプト、およびパッケージデータベースがインストールされます。

  6. SGD サーバーを停止します。

  7. SGD インストールディレクトリを削除します。


    # rm -rf /opt/tarantella
    

  8. バックアップから SGD インストールを復元します。



    注 - 必ずサーバーのバックアップから復元してください。また、ホストの DNS 名が変更されていないことを確認してください。



  9. SGD サーバーを再起動します。


アレイと負荷分散のトラブルシューティング

この節では、SGD サーバーの使用時に発生する一般的な問題、およびその解決方法について説明します。

ここで説明するトラブルシューティングの内容は次のとおりです。

Advanced Load Management に関するトラブルシューティング

アプリケーションの負荷分散を「最小 CPU 使用量」方式および「最大空きメモリー」方式で行うときに問題が発生する場合には、問題の理解に役立つ情報を次の場所から入手できます。

これらの情報を使用して、次の一般的な問題をトラブルシューティングできます。

負荷分散サービスが動作しない

負荷分散サービスが動作していないと考えられる場合は、次の点を確認してください。

SGD 拡張モジュールがインストールされていて、動作していますか。

Microsoft Windows アプリケーションサーバーの場合は、「コントロール パネル」 → 「管理ツール」 → 「サービス」を使用して、「Tarantella Load Balancing Service」が表示され開始されていることを確認します。

UNIX および Linux プラットフォームのアプリケーションサーバーの場合は、次のコマンドをスーパーユーザー (root) として実行して、負荷分散プロセスが稼働していることを確認します。


# /opt/tta_tem/bin/tem status

プライマリ SGD サーバーは動作していますか。

アプリケーションサーバー上の負荷分散サービスは、負荷情報をプライマリ SGD サーバーに送信します。プライマリを使用できない場合は、アプリケーションサーバーの負荷分散方式として「最少アプリケーションセッション数」が使用されます。

ファイアウォールが負荷分散サービスをブロックしていませんか。

負荷分散サービスが機能するには、ファイアウォールで次の接続を許可する必要があります。

  • SGD サーバーとアプリケーションサーバー間の TCP 接続 (ポート 3579)。

  • アプリケーションサーバーと SGD サーバー間の UDP 接続 (ポート 3579)。



注 - これらの接続では、認証は必要ありません。



ログファイルにはどのようなログが記録されていますか。

ログファイルで詳細情報を確認します。詳細については、Advanced Load Management に関するトラブルシューティング を参照してください。

SGD がアプリケーションサーバーの負荷分散プロパティーファイルを無視する

アプリケーションサーバーの負荷分散プロパティーファイルを作成したあとで、プライマリ SGD サーバーをウォームリスタートする必要があります。次のコマンドをスーパーユーザー (root) として実行してください。


# tarantella restart --warm

SGD サーバーにログインしているユーザーがいないことと、中断しているアプリケーションセッションも含め、SGD サーバー上で実行されているアプリケーションセッションがないことを確認します。

あるアプリケーションサーバーが 1 度も選択されない

アプリケーションを実行するサーバーとして、アプリケーションサーバーの 1 つが一度も選択されない場合は、次の点を確認してください。

そのアプリケーションサーバーで負荷分散サービスが実行されていますか。

負荷分散サービスが動作しないを参照してください。

そのアプリケーションサーバーを使用してアプリケーションを実行できますか。

Administration Console でアプリケーションサーバーオブジェクトを確認します。アプリケーションサーバーオブジェクトの「一般」タブの「アプリケーション起動」チェックボックスが選択されていることを確認します。

アプリケーションサーバーが稼働していることを確認します。

ログファイルにはどのようなログが記録されていますか。

ログファイルで詳細情報を確認します。詳細については、Advanced Load Management に関するトラブルシューティングを参照してください。

あるアプリケーションサーバーが常に選択される

アプリケーションを実行するサーバーとして、アプリケーションサーバーの 1 つが負荷に関係なく常に選択される場合は、次の点を確認してください。

アプリケーションを実行するために複数のアプリケーションサーバーが設定されていますか。

アプリケーションオブジェクトの「ホストしているアプリケーションサーバー」タブを確認します。

ほかのアプリケーションサーバーをアプリケーションの実行に使用できますか。

Administration Console でアプリケーションサーバーオブジェクトを確認します。「一般」タブの「アプリケーション起動」チェックボックスが選択されていることを確認します。

すべてのアプリケーションサーバーが稼働していることを確認します。

適切な負荷分散方式が選択されていますか。

Administration Console で、アプリケーションオブジェクトの「パフォーマンス」タブか、「グローバル設定」 → 「パフォーマンス」タブで、負荷分散方式として「最大空きメモリー」または「最小 CPU 使用量」のいずれかが選択されていることを確認します。

サーバーアフィニティーを使用していますか。

サーバーアフィニティーとは、ユーザーが最後に起動したアプリケーションと同じアプリケーションサーバー上で、アプリケーションを起動しようとすることです。サーバーアフィニティーは、デフォルトで有効になっています。サーバーアフィニティー を参照してください。

アプリケーションサーバーで負荷分散サービスが動作していますか。

負荷分散サービスが動作しないを参照してください。

ログファイルにはどのようなログが記録されていますか。

ログファイルで詳細情報を確認します。詳細については、Advanced Load Management に関するトラブルシューティングを参照してください。

同一のアプリケーションサーバーが 2 つ存在するが、一方が実行するアプリケーションの数が他方よりも多い

サーバー負荷係数値がどちらのサーバーも同じであることを確認します。アプリケーションサーバーの相対的な処理能力を参照してください。

SGD サーバーのログファイルに ID が不明の更新が着信したことが表示される

SGD サーバーのログファイルに、次のテキストを含む情報メッセージが表示されることがあります。

Got an update for unknown id from machine applicationserver

このメッセージは無視してもかまいません。このメッセージは、プライマリ SGD サーバーが再起動するときにのみ生成されます。

SGD が大量のネットワーク帯域幅を使いすぎる

SGD が大量のネットワーク帯域幅を使用している場合は、ユーザープロファイルの「帯域幅の制限」属性を変更して、ユーザーが使用可能な最大帯域幅を減らします。



注 - 使用できる帯域幅を減らすと、アプリケーションの使い勝手に影響する場合があります。



Administration Console で、「ユーザープロファイル」タブに移動し、設定するユーザープロファイルオブジェクトを選択します。「パフォーマンス」タブに移動し、「帯域幅の制限」リストから値を選択します。

または、次のコマンドを実行します。


$ tarantella object edit --name obj --bandwidth bandwidth

使用可能な帯域幅は次のとおりです。


Administration Console コマンド行
2400 bps 2400
4800 bps 4800
9600 bps 9600
14.4 Kbps 14400
19.2 Kbps 19200
28.8 Kbps 28800
33.6 Kbps 33600
38.8 Kbps 38800
57.6 Kbps 57600
64 Kbps 64000
128 Kbps 128000
256 Kbps 256000
512 Kbps 512000
768 Kbps 768000
1 Mbps 1000000
1.5 Mbps 1500000
10 Mbps 10000000
なし 0



注 - デフォルトは「None」です。これは、帯域幅の使用に制限がないことを意味します。



ファイアウォール越えモード時にユーザーが SGD サーバーに接続できない

ファイアウォール越えモード時にユーザーが SGD サーバーに接続できない場合は、通常、SGD サーバーが SGD Web サーバーより前に起動したことが原因です。

ファイアウォール越えモードの場合、SGD サーバーはポート 443 で待機して、すべての Web 接続を localhost ポート 443 (127.0.0.1:443) 上で待機するよう設定されている SGD Web サーバーに転送します。

SGD サーバーが SGD Web サーバーより前に起動した場合、SGD サーバーは使用可能なすべてのインタフェースへのバインドを実行します。このため、SGD サーバーはすべての Web 接続を自分自身に転送して無限ループに陥ります。

1 つの解決策は、SGD Web サーバーを常に SGD サーバーより前に起動することです。

別の解決策は、localhost インタフェースへのバインドを実行しないように SGD を設定することです。これを実行するには、次のコマンドを使用します。


 $ tarantella config edit \
--tarantella-config-server-bindaddresses-external "!127.0.0.1"



注 - 一部のシェルでは、二重引用符を使用できません。これは、"!127.0.0.1" とした場合の!127 が置き換えられる場合があるためです。代わりに一重引用符 '!127.0.0.1' を使用してください。



SGD がバインドするインタフェースを正確に指定する場合にも、このコマンドを使用できます。この場合は、DNS 名または IP アドレスのコンマ区切りのリストを入力します。

ファイアウォール越えモードでの SGD の実行に関する詳細については、ファイアウォール越えの使用を参照してください。

ユーザーが自分のセッションを再配置できない

ユーザーが SGD サーバーからログアウトせずに別の SGD サーバーにログインする場合、通常、ユーザーのセッションが新規サーバーに再配置されます。これは、「セッションの移動」または「セッションの乗っ取り」と呼ばれることがあります。

アレイ内のすべての SGD サーバーの時刻が同期されていない場合、ユーザーセッションの再配置が成功しないことがあります。

SGD は、ユーザーセッション上のタイムスタンプを使って、どれが新しいかを判断します。新しい方のユーザーセッションが現在の Webtop セッションと見なされます。時刻が同期されていないと、タイムスタンプは、誤った情報を与える場合があります。

時刻の同期は重要であるため、NTP ソフトウェアを使って時刻を同期します。または、rdate コマンドを実行します。

SGD のユーザーセッションの詳細については、セッション を参照してください。