第 7 章 |
この章では、SGD サーバーおよびアレイの設定、ライセンス管理、および監視を行う方法について説明します。Administration Console、ログフィルタ、インストールのバックアップなど、SGD のシステム管理機能の一部についても説明します。
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 でのみ接続を受け入れます。
アレイメンバー間の接続を認証するために、アレイメンバーのみが知っている共有シークレットが使用されます。Secret Key Identification (SKID) 認証が使用されます。SKID 認証ではデータは暗号化されません。
ほとんどの接続は、プライマリサーバーからセカンダリサーバーに対して行われます。このような接続でデータが複製され、アレイの同期が保たれます。ただし、アレイメンバーはほかのアレイメンバーと直接通信できる必要があります。
アレイに対する SGD サーバーの追加や削除は、Administration Console または tarantella array コマンドを使用して行います。
すべてのアレイ操作は、アレイのプライマリ SGD サーバーで実行することが最善です。
「Secure Global Desktop サーバーのリスト」の「追加」ボタンをクリックします。
「Secure Global Desktop サーバーの追加」画面が表示されます。
ヒント - tarantella array join コマンドを使用してアレイに SGD サーバーを追加することもできます。 |
「Secure Global Desktop サーバー」タブが表示されます。
「Secure Global Desktop サーバー」タブには、サーバーの変更処理と同期処理が完了するまで待つように勧めるメッセージが表示されます。
注 - アレイの構造に変更を加えた場合は、その変更がアレイ内のすべての SGD サーバーにコピーされるのを待ってから、次の変更を行うようにしてください。プライマリ SGD サーバーで tarantella status コマンドを実行して、アレイの状態を確認してください。 |
Advanced Load Management を使用する負荷分散アプリケーションサーバーを追加する場合は、アレイに追加したあとにウォームリスタートを実行する (tarantella restart --warm) 必要があります。Advanced Load Management の仕組み も参照してください。
「Secure Global Desktop サーバーのリスト」の「削除」ボタンをクリックします。
ヒント - tarantella array detach コマンドを使用してアレイから SGD サーバーを削除することもできます。 |
「Secure Global Desktop サーバー」タブには、サーバーの変更処理と同期処理が完了するまで待つように勧めるメッセージが表示されます。
注 - アレイの構造に変更を加えた場合は、その変更がアレイ内のすべての SGD サーバーにコピーされるのを待ってから、次の変更を行うようにしてください。プライマリ SGD サーバーで tarantella status コマンドを実行して、アレイの状態を確認してください。 |
「Secure Global Desktop サーバーのリスト」の「プライマリ化」ボタンをクリックします。
ヒント - tarantella array make_primary コマンドを使用してアレイのプライマリサーバーを変更することもできます。 |
「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 に最初に接続する前に行われます。多数の機構を使って、適切な SGD サーバーを選択できます。次に例を示します。
ユーザーセッションの負荷分散におけるもっとも重要な要素は、セッションの持続性です。ユーザーセッションは、ユーザーが SGD サーバーにログインした時点で始まり、そのサーバーによって所有されます。ユーザーが SGD とやりとりすると、さらに要求が HTTP (Hypertext Transfer Protocol) 接続を介して SGD サーバーに送信されます。ネットワーク接続の負荷分散が行われている場合、HTTP 要求はアレイ内の任意の SGD サーバーに転送される可能性があります。HTTP 要求がそのユーザーセッションを所有していない SGD サーバーに送信されると、次のことが発生する可能性があります。
ユーザーセッションの負荷分散を正常に行うには、HTTP 要求が常に正しい SGD サーバーに送信されるように「持続」する必要があります。
SGD のデフォルトインストールでは、HTTP 接続を持続させるためには負荷分散 JSP を使用して追加設定を行う必要があります。JSP には Cookie を設定する JavaScript スクリプトが含まれており、その Cookie は HTTP 要求を正しいサーバーにリダイレクトするために使用されます。
負荷分散 JSP は、次の条件が満たされている場合にのみ使用できます。
ラウンドロビン機構を使用して、JSP が SGD サーバーをリストから選択する。負荷分散 JSP を使用してユーザーセッションを分散するを参照してください。
JSP が SGD サーバーを選択するための外部機構をサポートする。外部機構を使用してユーザーセッションを分散するを参照してください。
負荷分散 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 を次のように設定します。
負荷分散 JSP ファイルを /sgd Web アプリケーションディレクトリにコピーします。
# cd /opt/tarantella/webserver/tomcat/5.0.28_axis1.2/webapps/sgd/ # cp -rp admin/loaddist/ swcd/ |
負荷分散の対象となる SGD サーバーの外部 DNS 名を追加します。
詳細については、外部 DNS 名の設定を参照してください。
hosts = new Array セクションを修正します。次に例を示します。
hosts[0] = "http://www1.example.com" hosts[1] = "http://www2.example.com" ... hosts[4] = "http://www5.example.com"
var LBHOST = null // Not in Load Balancer/Round Robin DNS mode
ハードウェアロードバランサやラウンドロビン 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 への接続は次のように処理されます。
ロードバランサは、SSL 要求を復号化し、選択された SGD サーバーの外部 DNS 名に HTTP 要求として転送します。
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) 経由で確立されます。ファイアウォール越えの使用を参照してください。
負荷分散 JSP ファイルを /sgd Web アプリケーションディレクトリにコピーします。
# cd /opt/tarantella/webserver/tomcat/5.0.28_axis1.2/webapps/sgd/ # cp -rp admin/loaddist/ swcd/ |
負荷分散の対象となる SGD サーバーの外部 DNS 名を追加します。
詳細については、外部 DNS 名の設定を参照してください。
hosts = new Array セクションを修正します。次に例を示します。
hosts[0] = "http://www1.example.com" hosts[1] = "http://www2.example.com" ... hosts[4] = "http://www5.example.com"
最初のコメント記号 (//) を削除し、SGD サーバーの外部 DNS 名を入力します。次に例を示します。
var LBHOST = "http://www1.example.com" // LB mode
My Desktop の機能の詳細については、My Desktop の使用を参照してください。
負荷分散 JSP ファイルを /sgd/mydesktop Web アプリケーションディレクトリにコピーします。
# cd /opt/tarantella/webserver/tomcat/5.0.28_axis1.2/webapps/sgd/ # cp -rp admin/loaddist/ mydesktop/swcd/ |
負荷分散 JSP を使用するように My Desktop を設定します。
My Desktop のエントリポイント JSP の名前を変更します。
エントリポイント JSP は mydesktop/index.jsp です。
# mv mydesktop/index.jsp mydesktop/mydesktop.jsp |
My Desktop の新しいエントリポイント JSP を作成します。
次の内容を含む新しい JSP ファイル mydesktop/index.jsp を作成します。
<%@ include file="/mydesktop/swcd/swcd.jsp" %>
My Desktop の JSP ファイルのファイルアクセス権を確認します。
# chmod root:ttaserv mydesktop/index.jsp mydesktop/mydesktop.jsp |
負荷分散 JSP は mydesktop/swcd/swcd.jsp です。
負荷分散の対象となる SGD サーバーの外部 DNS 名を追加し、LBHOST 変数を設定します。
負荷分散 JSP を使用してユーザーセッションを分散する場合は、負荷分散 JSP を設定してユーザーセッションを分散する方法の手順 3 を参照してください。
外部機構を使用してユーザーセッションを分散する場合は、外部負荷分散メカニズムのために負荷分散 JSP を設定する方法の手順 3 を参照してください。
ユーザーを Webtop にではなく My Desktop に送るように、TARGET 変数を変更する必要があります。
var TARGET="/sgd/mydesktop/mydesktop.jsp"
ここでは、負荷分散 JSP で使用できる追加の設定について説明します。
負荷分散 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/"; %>
アプリケーションセッションの負荷分散は、アプリケーションセッションを管理する 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 つだけです。
サーバーアフィニティーの値を変更するには、次のコマンドを実行します。
$ tarantella config edit \ --tarantella-config-applaunch-appserveraffinity 0|100 |
![]() | 注意 - Windows アプリケーションを使用している場合、この値を変更することはお勧めしません。これは、複数のアプリケーションサーバーを使用する場合に、問題 (特にローミングプロファイルの問題) が発生するためです。また、同じアプリケーション群に属する複数のアプリケーションを互いに異なるサーバー上で実行すると、ライセンスの問題が発生することがあります。 |
SGD では、アプリケーションサーバーの相対的な処理能力を考慮して、アプリケーションの起動場所を決定できます。
相対的な処理能力は、パーセントで表現されます。デフォルトでは、すべてのサーバーに値 100 が割り当てられます。サーバーの負荷分散プロパティー weighting を編集してその負荷係数を増減すると、SGD によってアプリケーションサーバーが選択される可能性を増減できます。負荷係数の詳細については、アプリケーションの負荷分散の調整を参照してください。
アプリケーションサーバーの相対的な処理能力を使用して、次の操作を実行できます。
特定のサーバー上で起動するアプリケーションセッションの数を減らす。たとえば、特定のサーバーを SGD 以外のプロセスで使用する場合に、この操作を行います。
特定のサーバー上で起動するアプリケーションセッションの数を増やす。たとえば、あるサーバーが CPU 容量は小さくても IO(入出力) 性能が優れている場合に、この操作を行います。
負荷係数の使用方法の詳細については、もっとも負荷の少ないアプリケーションサーバー の負荷計算を参照してください。
SGD では、もっとも負荷の少ないアプリケーションサーバーを選択する方式がいくつかサポートされています。
デフォルトの方式は、Administration Console の「グローバル設定」 → 「パフォーマンス」タブで設定します。アプリケーションオブジェクトの「パフォーマンス」タブに異なる方式を指定することで、デフォルトを上書きできます。この方法を利用すれば、アプリケーションの負荷分散をさまざまな方法で行うことができます。
アプリケーションの負荷分散の方式として、次のものがサポートされています。
「最小 CPU 使用量」方式および「最大空きメモリー」方式では、ユーザーがアプリケーションを起動した時点の「アプリケーションサーバーの実際の負荷」が計算されます。これは Advanced Load Management と呼ばれます。詳細については、Advanced Load Management の仕組みを参照してください。
「最少アプリケーションセッション数」方式を使用した場合は、実行中のアプリケーションセッションがもっとも少ないアプリケーションサーバーが選択されます。この選択は、SGD から運用しているアプリケーションセッション数のみに基づいて行われます。
アプリケーションの起動時にアレイからアプリケーションサーバーの負荷情報を取得できないなどの理由で、Advanced Load Management の使用で問題が発生した場合は、代わりに「最少アプリケーションセッション数」方式が使用されます。こうした状況は、プライマリ SGD サーバーを再起動しているときなどに発生することがあります。
アプリケーションサーバーの負荷計算には、次の数式が使用されます。
アプリケーションセッションの数 x 100 / サーバーの負荷係数
ここでは、アプリケーション負荷分散の「最少アプリケーションセッション数」方式を使用して負荷を計算する例を紹介します。
現在、アプリケーションサーバー london では 10 個のアプリケーションセッションが動作しています。負荷係数値は 100 です。
現在、アプリケーションサーバー paris では 12 個のアプリケーションセッションが動作しています。負荷係数値は 100 です。
10 x 100 / 100 = 10
12 x 100 / 100 = 12
その他のアプリケーション起動条件が満たされている場合は、それ以降の 2 つのアプリケーションセッションの起動に london が使用されます。london のサーバー負荷係数値を 50 に下げた場合、london の負荷は 20 (10 x 100 / 50) になるため、それ以降の 8 個のアプリケーションセッションの起動には paris が選択されます。
「最小 CPU 使用量」方式を使用した場合は、CPU アイドル時間のもっとも長いアプリケーションサーバーが選択されます。この方式は、プロセッササイクルを大量に必要とするアプリケーションに適しています。
この方式では、アプリケーションサーバーの負荷が CPU 性能 (単位は BogoMips) および CPU 使用量に基づいて測定されます。測定は、負荷分散サービスが行ないます。
(BogoMips x CPU アイドル率) x 負荷係数 / 100
ここでは、アプリケーション負荷分散の「最小 CPU 使用量」方式を使用して負荷を計算する例を紹介します。
アプリケーションサーバー london の CPU 性能は 500 BogoMips、サーバー負荷係数値は 75、CPU アイドル率は 25% です。
アプリケーションサーバー paris の CPU 性能は 100 BogoMips 、サーバー負荷係数値は 100、CPU アイドル率は 50% です。
(500 x 25) x 75 / 100 = 9375
(100 x 50) x 100 / 100 = 5000
その他のアプリケーション起動条件が満たされている場合は、paris の方が CPU 使用率が低く、サーバーの負荷係数値が高くても、london がアプリケーションサーバーとして選択されます。
「最大空きメモリー」方式を使用した場合は、空き仮想メモリー容量のもっとも多いアプリケーションサーバーが選択されます。この方式は、大量のメモリーを必要とするアプリケーションに適しています。
この方式では、アプリケーションサーバーの実仮想メモリーと現在使用中のメモリー容量を比較して、アプリケーションサーバーの負荷が測定されます。測定は、負荷分散サービスが行ないます。
仮想メモリーの空き容量 x 負荷係数 / 100
Advanced Load Management では、アプリケーションが起動された時点でそのアプリケーションサーバーに割り当てられている空きメモリー量または空き CPU 時間のどちらかに基づいてアプリケーションの負荷を分散できます。これらの方式を使用して負荷分散を行えるのは、X アプリケーション、Windows アプリケーション、および文字型アプリケーションに対してだけです。
Advanced Load Management を使用するには、すべてのアプリケーションサーバーに SGD 拡張モジュールをインストールする必要があります。これにより、負荷分散サービスがインストールされます。このサービスは、アプリケーションサーバーの CPU やメモリーの負荷に関する情報を SGD にリアルタイムで提供します。また、これは、アプリケーションサーバーが使用不可かどうかを SGD が容易に検出できるようにもします。たとえば、再起動する場合などです。
プライマリ SGD サーバーは、起動するたびに、負荷分散のために考慮する必要のあるアプリケーションサーバーのリストを作成します。このリストは、ホストのアプリケーションへの割り当てまたはアプリケーションからの削除が行われるたびに更新されます。
プライマリ SGD サーバーは、負荷分散対象アプリケーションサーバーのそれぞれに接続し、初期の負荷情報を要求します。そのために、各アプリケーションサーバーの TCP ポート 3579 上の負荷分散サービスに接続します。また、この接続が確立できれば、アプリケーションサーバーがアプリケーションを実行可能であることを確認できたことにもなります。
プライマリ SGD サーバーは、アレイ内のセカンダリサーバーに更新を送信します。この更新には、各方式に対する容量値と、使用不可のアプリケーションサーバーに関する情報が含まれています。
負荷分散サービスは、UDP ポート 3579 を使用して、定期的な更新をプライマリ SGD サーバーに送信します。この更新は、負荷に変化がない場合でも発生します。この定期的な更新が途絶えるかどうかによって、SGD は、各アプリケーションサーバーがアプリケーションを実行可能かどうかを判断することができます。
プライマリ SGD サーバーは、アレイ内のセカンダリサーバーに定期的な更新を送信します。この更新には、各方式に対する容量値と、使用不可のアプリケーションサーバーに関する情報が含まれています。この更新は、負荷に変化がない場合でも発生します。
注 - 負荷分散サービスは常に、プライマリ SGD サーバーに対してアプリケーションサーバーの負荷データを送信します。プライマリサーバーが使用不可の場合は Advanced Load Management も使用できないため、セカンダリサーバーは代わりに、セッションに基づくデフォルトの負荷分散に戻ります。 |
SGD 管理者は、アプリケーションの負荷分散プロパティーを編集することによって、アプリケーションの負荷分散を調整できます。これらのプロパティーは、Advanced Load Management に使用される負荷分散サービスがどのように動作するか、および SGD がアプリケーションサーバーの負荷をどのように計算するかを制御します。アプリケーションの負荷分散をグローバルに調整することも、個々のアプリケーションサーバーに対して調整することもできます。負荷分散プロパティーの編集方法の詳細については、アプリケーションの負荷分散プロパティーの編集 を参照してください。
アプリケーションの負荷分散を調整する前に、必ず次の項目を読み、理解しておいてください。
アプリケーションの負荷分散の動作を次の点で調整することができます。
![]() | 注意 - アプリケーションサーバーの相対的な処理能力の調整を除き、この調整は Advanced Load Management を使用している場合にのみ使用できます。 |
weighting プロパティーを使用すると、アプリケーションサーバーの相対的な処理能力を考慮して、アプリケーションの起動場所を SGD で決定できます。詳細については、アプリケーションサーバーの相対的な処理能力 を参照してください。
アレイのプライマリ SGD サーバーは、TCP ポート 3579 を使用してアプリケーションサーバーの SGD 負荷分散サービスと対話します。この動作は、listeningport プロパティーによって制御されます。
負荷分散サービスは、UDP (ユーザーデータグラムプロトコル) ポート 3579 を使用して、更新をプライマリ SGD サーバーに送信します。この動作は、probe.listeningport プロパティーによって制御されます。
これらのポートは Internet Assigned Numbers Authority (IANA) に登録され、SGD 専用として予約されています。これらのプロパティーの変更は、Sun のサポートから依頼された場合にのみ行なってください。プライマリ 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 日の始めにアプリケーションを起動し、その日の終わりにアプリケーションを閉じる場合は、負荷計算の頻度を下げます。逆に、ユーザーがアプリケーションの起動と停止を繰り返す場合は、負荷計算の頻度を上げます。
replyfrequency プロパティーは、負荷分散サービスがプライマリ SGD サーバーに更新を送信する間隔を制御しています。
percentagechange プロパティーは、使用される CPU/メモリーの増減率のしきい値を制御しています。使用率がこのしきい値以上に増減したら、プライマリ SGD サーバーに報告されるものとします。負荷分散サービスは、使用率が変化するとすぐに、更新を送信します。たとえば、アプリケーションサーバーが 30% の CPU 負荷で動作し、percentchange の値が 10 の場合は、負荷が 20% または 40% になると更新が発生します。負荷分散サービスは、使用率が突然大きく変化する状況にも対応していて、このような場合にも調整を行います。たとえば、percentagechange の値が 20% であるのに、サーバーの CPU 負荷が 81% に達した場合にも対応することができます。
replyfrequency の更新は、負荷が変化していない場合や、percentagechange の更新が発生した場合にも送信されます。percentagechange 計算の基になる値は、replyfrequency の更新が送信されるたびに再設定されます。
updatelimit x replyfrequency 秒の間にアプリケーションサーバーから更新が送信されない場合、SGD はアプリケーションサーバーとの接続が切断されていると見なします。つまり、そのアプリケーションサーバーは、SGD サーバーとの接続を再度確立できる状態になるまでは、アプリケーションを起動できないサーバーと見なされます。
SGD は、updatelimit x replyfrequency 秒の間にアプリケーションサーバーから更新が送信されない場合、CPU およびメモリーに関して受信したデータの信頼性が低いと見なします。
信頼性の低いデータは、アプリケーションをどのサーバーで起動するかを決定するときに無視されます。つまり、そのアプリケーションサーバーはキューの最後に移動し、アプリケーションを起動するために他のサーバーが利用できないか適切でない場合にだけ使用されます。
SGD のアプリケーション負荷分散は、アプリケーションサーバーの負荷分散のプロパティーを編集することによって調整できます。負荷分散プロパティーは、プロパティーファイルに保存されていて、テキストエディタを使って編集できます。次の 3 つのプロパティーファイルがあります。
グローバルプロパティーファイル - このファイルには、アレイ内のすべての SGD サーバーに対するデフォルト設定が含まれています。
アプリケーションサーバーのプロパティーファイル - このファイルを使用すると、特定のアプリケーションサーバーについて、グローバルプロパティーファイルでのデフォルト設定の一部を上書きできます。
負荷分散サービスのプロパティーファイル - このファイルには、UNIX または Linux プラットフォームのアプリケーションサーバー上で負荷分散サービスが初回起動時または再起動時に使用する設定が含まれています。
この節では、プロパティーファイルの編集方法と編集可能なプロパティーについて説明します。プロパティーの使用方法の詳細については、アプリケーションの負荷分散の調整 を参照してください。
![]() | 注意 - アプリケーションが起動できなくなる可能性があるため、これらのプロパティーを編集する際は慎重に行なってください。 |
グローバル負荷分散プロパティーファイルには、アレイ内のすべての SGD サーバーに対するデフォルトの負荷分散プロパティーが含まれています。
このファイルは /opt/tarantella/var/serverconfig/global/tier3lb.properties です。
![]() | 注意 - これらの負荷分散プロパティーは、アレイのプライマリ 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
アプリケーションサーバー固有の負荷分散プロパティーファイルを作成することにより、グローバル負荷分散プロパティーの一部を上書きできます。このファイルは、アプリケーションサーバーの負荷分散プロパティーファイルを作成する方法 の説明に従って、「手動」で作成する必要があります。
サーバー固有のプロパティーファイルのプロパティーには、tarantella.config.tier3hostdata.weighting のように、プロパティー名の前に tarantella.config.tier3hostdata という接頭辞が付いています。
プライマリ SGD サーバーにスーパーユーザー (root) としてログインします。
![]() | 注意 - 負荷分散プロパティーファイルは、アレイ内のプライマリ SGD サーバーでのみ作成してください。このファイルは、プライマリサーバーからセカンダリサーバーにコピーされます。 |
/opt/tarantella/var/serverconfig/global/t3hostdata ディレクトリに移動します。
template.properties ファイルをコピーして、同じディレクトリに hostname.properties という名前のファイルを作成します。ここで、hostname はアプリケーションサーバーの名前で、たとえば paris.indigo-insurance.com.properties となります。
# tarantella restart --warm |
負荷分散サービスのプロパティーファイルには、UNIX または Linux プラットフォームのアプリケーションサーバー上で負荷分散サービスが初回起動時および再起動のたびに使用する設定が含まれています。
![]() | 注意 - これらのプロパティーの変更は、Sun のサポートから依頼された場合か、アプリケーションサーバーの物理メモリーまたは仮想メモリーを変更したときに SGD 拡張モジュールを再インストールしなかった場合のみ行なってください。 |
負荷分散サービスのプロパティーファイルは /opt/tta_tem/var/serverconfig/local/tier3loadbalancing.properties です。
これらのプロパティーを変更する場合は、手動で負荷分散サービスを停止して再起動する必要があります。
負荷分散サービスのプロパティーファイルのプロパティーには、tarantella.config.tier3loadbalancing.weighting のように、プロパティー名の前に tarantella.config.tier3loadbalancing という接頭辞が付いています。
この節では、SGD に含まれている Web サーバーの設定方法について説明します。この 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 をインストールする際に、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 サーバーはセキュア (HTTPS) Web サーバーとして設定され、SGD セキュリティーサービスに使用されるサーバー証明書を共有します。SGD Web サーバーへの HTTPS 接続の使用を参照してください。
SGD サーバーアレイ内のすべての Web サーバーが、同一の HTTP または HTTPS ポートを使用する必要があります。同一 SGD アレイ内で HTTP Web サーバーと HTTPS Web サーバーを混在させることはできません。
Web サーバーとのセキュリティー保護された接続を有効にした場合、クライアントプロファイルの URL を HTTPS URL に再設定する必要があります。クライアントプロファイルの設定を参照してください。
この節では、SGD 管理者が Administration Console を実行および設定する方法について説明します。
この節では、Administration Console を実行する方法について説明します。Administration Console を使用する際の一般的ないくつかの問題について、回避方法の詳細も説明します。
Administration Console を表示するには、SGD でサポートされている、Safari 以外の任意のブラウザを使用できます。SGD でサポートされているブラウザの詳細については、サポートされるクライアントプラットフォーム を参照してください。ブラウザで JavaScript プログラミング言語が有効になっている必要があります。
![]() | Caution - Administration Console の使用中は、ブラウザの「戻る」ボタンを使用しないでください。代わりに、「オブジェクトビューへジャンプ」リンク、「ナビゲーションビューへジャンプ」リンク、または「オブジェクト履歴」リストを使用して、Administration Console のページ間を移動します。 |
Administration Console は、アレイ内のプライマリ SGD サーバー上で実行すると最適に機能します。
Administration Console は、次のいずれかの方法で起動できます。
http://server.example.com の SGD Web サーバーの開始画面で、「Sun Secure Global Desktop Administration Console の起動」リンクをクリックします。ここで、server.example.com は SGD サーバーの名前です。
注 - Administration Console は SGD 管理者専用です。Administration Console を使用するには、SGD 管理者としてログインするか、SGD 管理者としてログイン済みであることが必要です。 |
Administration Console は、SGD Web サーバーで使用する場合のみサポートされています。
Administration Console には、Web アプリケーションアーカイブ (WAR) ファイル sgdadmin.war が付属しています。このファイルを使って Administration Console を別の Web アプリケーションサーバーに再配備することはできません。
アレイ内の任意の SGD サーバーから Administration Console を使用して、SGD データストアに対して新規オブジェクトの作成やオブジェクトの属性の編集といった操作を実行できます。
SGD データストアを編集すると、変更内容がプライマリ SGD サーバーに送信されます。その後、プライマリ SGD サーバーからアレイ内のすべてのセカンダリサーバーに、これらの変更が複製されます。
Administration Console をプライマリ SGD サーバーから実行することで、次の原因による問題を回避できます。
アレイの結合や切り離しといったアレイ操作を Administration Console で実行する場合は、次の制限が適用されます。
プライマリ SGD サーバーを使用してください。Administration Console をプライマリサーバー上で実行することで、データ複製の問題を回避できます。SGD データストアの更新の問題を回避するも参照してください。
アレイ操作に関連するサーバーはすべて稼働している必要があります。たとえば、Administration Console を使用して、停止しているセカンダリサーバーを切り離すことはできません。代わりに、tarantella array detach コマンドを使用してください。
Administration Console は、JavaHelp ソフトウェアを使ってオンラインヘルプを表示します。ただし、SGD
Web サーバーへの HTTPS 接続が有効になっている場合、オンラインヘルプは使用不可になります。
HTTPS 接続を介して JavaHelp を実行するには、SGD Web サーバーの証明書の署名に使用された CA (認証局) 証明書または CA 証明書チェーンが CA 証明書トラストストアに含まれている必要があります。デフォルトでは、SGD Web サーバーは SGD サーバーと同じ証明書を使用します。詳細については、CA 証明書トラストストアを参照してください。
Administration Console Web アプリケーションの配備記述子には、Administration Console の処理を制御する設定が入っています。配備記述子は次のファイルです。
/opt/tarantella/webserver/tomcat/5.0.28_axis1.2/sgdadmin/WEB-INF/web.xml
この節では、ユーザーが設定する可能性のある配備記述子の設定について説明します。設定のほとんどは、<context-param> 要素に含まれているコンテキストパラメータです。web.xml ファイル内のその他の設定は変更しないでください。
配備記述子の設定を操作する場合は、次の点に留意してください。
以前のバージョンに戻す必要が生じる場合に備えて、常に元の web.xml のバックアップを作成して保存してください。その方法については、SGD インストールのバックアップと復元 を参照してください。
web.xml に対する変更は Administration Console をホストしているサーバーにのみ適用されます。
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 秒待機してから、処理を続行します。
com.sun.tta.confmgr.LdapSearchTimeLimit コンテキストパラメータを使用すると、LDAP ディレクトリの検索に許容する最大の時間をミリ秒単位で設定できます。デフォルト値は 0 で、検索時間に制限がないことを意味します。特に低速な LDAP ディレクトリサーバーを使用している場合のみ、このコンテキストパラメータを変更してください。
次のコンテキストパラメータは、Administration Console で LDAP データの表示を絞り込むために使用します (「リポジトリ」リストで「ローカル + LDAP」を選択した場合)。
ユーザープロファイルの「割り当て済みのアプリケーション」タブの 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 は 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 分を加えた値がタイムアウト期間になります。
Administration Console では、次の手順でアプリケーションセッションを一覧表示できます。
SGD サーバーの「アプリケーションセッション」タブには、そのサーバーでホストされているすべてのアプリケーションセッションが表示されます。
ユーザープロファイルの「アプリケーションセッション」タブには、そのユーザープロファイルに関連付けられているすべてのアプリケーションセッションが表示されます。
アプリケーションサーバーの「アプリケーションセッション」タブには、そのアプリケーションサーバーで実行されているすべてのアプリケーションが表示されます。
「アプリケーションセッション」タブでは、各アプリケーションセッションの詳細を表示できます。また、アプリケーションセッションを終了したりシャドウィングしたりすることもできます。セッションをシャドウィングすると、管理者とユーザーが同じアプリケーションを同時に使って対話することができます。
アプリケーションセッションのシャドウィングの詳細については、ユーザーの問題を解決するためのシャドウイングの使用 を参照してください。
注 - シャドウィングできるのは、Windows アプリケーションと X アプリケーションだけです。アプリケーションセッションを中断してはいけません。 |
コマンド行からユーザーセッションを一覧表示したり終了したりするには、tarantella emulatorsession コマンドを使用します。
匿名ユーザー。ユーザー名とパスワードを入力せずにログインするユーザーです。匿名ユーザーの認証を参照してください。
共有ユーザー。「ゲストユーザー」とも呼ばれます。同じユーザー名とパスワードを使ってログインするユーザーです。ゲストユーザー用の共有アカウントの使用を参照してください。
これらのユーザーを区別するために、ゲストユーザーと匿名ユーザーにはログイン時に SGD によって一時的なユーザー識別情報が割り当てられます。これは次の影響を与えます。
SGD の初回インストール時に、デフォルトのログフィルタに SGD サーバーのエラーがすべて記録されます。問題解決などのため、より詳細な情報が必要な場合は、追加のログフィルタを設定できます。
Administration Console の「グローバル設定」 → 「監視」タブで、「ログフィルタ」フィールドにフィルタを入力します。各フィルタは、Return キーを押して区切る必要があります。
$ tarantella config edit --array-logfilter filter... |
component/subcomponent/severity:destination
フィルタの各部分のオプション、およびログ出力の表示方法については、以降の節で説明します。
注 - ログフィルタにより、大量のデータが生成される可能性があります。フィルタは可能なかぎり具体的に設定し、不要になったら削除することをお勧めします。 |
コンポーネントおよびサブコンポーネントを選択することで、SGD サーバーから記録したい情報の分野を選択できます。
次の表に、使用可能なコンポーネントとサブコンポーネントの組み合わせ、および各組み合わせで得られる情報の種類について説明します。
各ログフィルタについて、次の重要度レベルのいずれかを選択できます。
重要度 | 説明 |
---|---|
fatalerror | 致命的エラーに関する情報をログに記録します。致命的エラーが発生すると、SGD サーバーは実行を停止します。SGD の初回インストール時には、すべての致命的エラーがデフォルトでログに記録されます。 |
error | 発生したすべてのエラー情報をログに記録します。SGD の初回インストール時には、すべてのエラーがデフォルトでログに記録されます。 |
warningerror | システムリソースの減少などの、発生したすべての警告に関する情報をログに記録します。SGD の初回インストール時には、すべての警告がデフォルトでログに記録されます。 |
info | 情報ログ。バグの解決や識別に役立ちます。 |
moreinfo | 詳細な情報ログ。 |
auditinfo | SGD サーバー設定の変更など、選択したイベントのログを監査目的で記録します。詳細については、次を参照してください, ログフィルタを使用した監査. |
重要度 fatalerror の場合に、生成される情報がもっとも少なくなります。重要度 moreinfo の場合に、生成される情報量がもっとも多くなります。
重要度レベルの選択は、累積的ではありません。たとえば、info を選択しても、warningerror または fatalerror ログメッセージは表示されません。
ログファイルに出力する場合、次の種類のファイルに出力が可能です。
tarantella query errlog コマンドの実行には、この形式が必須です。このコマンドは、名前の末尾が error.log であるログファイルだけを検索します。
ファイルの形式は、出力先ファイルのファイル拡張子により制御されます。
ファイル名に %%PID%% プレースホルダーを含めることで、プロセス ID ごとに別個のログファイルを作成することもできます。
ログファイルは、/opt/tarantella/var/log ディレクトリに出力されます。ログファイルの位置を変更することはできませんが、シンボリックリンクを使用してログを別の場所にリダイレクトできます。また、syslog ログハンドラを使用することもできます。詳細は、ログハンドラの使用 を参照してください。
ログハンドラは、ログメッセージの出力先として使用される JavaBeans コンポーネントです。ログハンドラを指定する場合は、その完全な名前を使用する必要があります。SGD
では、次のログハンドラが提供されます。
server/login/*:login%%PID%%.log server/login/*:login%%PID%%.jsl
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
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 検索フィルタです。このコマンドで、ログファイルのログフィールドから該当するエントリを検索して表示します。次の表に、監査の際に特に役立つログフィールドを示します。
注 - すべてのログフィールドのリストは、/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) サービスが停止しました。 |
SGD には、「評価モード」と「フルライセンスモード」の 2 種類のライセンスモードがあります。
ライセンスモード | 説明 |
---|---|
評価モード | |
フルライセンスモード |
SGD の評価期間に、ブラウザを使って SGD にログインすると、評価期間の残りの日数が表示されます。
30 日間の評価期間が満了したあと、ユーザーが Webtop にログインすることや、アプリケーションを起動または再開することはできなくなります。SGD を引き続き使用するには、ライセンスキーを取得してインストールする必要があります。
ライセンスキーの追加は、Administration Console の「グローバル設定」 → 「ライセンス」タブで行います。また、tarantella license add コマンドを使用することもできます。
ライセンスキーをインストールすると、ロックされているソフトウェア機能が解除されます。ライセンスには、次の種類のいずれかです。
次の表に、使用可能なライセンスの種類とそのベース、およびそのライセンスで利用可能な機能を示します。
ライセンスの種類 | ベース | ソフトウェア機能 |
---|---|---|
基本コンポーネント | ユーザー | 次の基本機能を使用できます。 |
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 をログアウトした場合、アプリケーションはタイムアウトするまで実行し続け、コネクティビティーコンポーネントを使用し続けます。デフォルトのタイムアウトの長さは 8 日間です。
ユーザーが SGD にログインしても、アプリケーションを一切実行できない場合があります。これは、基本コンポーネントライセンスは使用可能であるが、すべてのコネクティビティーライセンスが、ログインしていないがアプリケーションセッションを中断しているユーザーに使用されているためです。
SGD は、ユーザーがソフトウェアコンポーネントを使用する際に、ライセンスの割り当ておよび解除を自動的に行います。SGD 管理者は、ユーザーの SGD セッションおよびアプリケーションセッションを終了させることはできても、ライセンスの割り当ておよび解除を手動で実行することはできません。
SGD ログファイルには、すべてのライセンス使用状況が経時的に記録されます。管理者 は tarantella license query コマンドを使用して、現在と過去のライセンス使用状況を表示できます。
SGD には、Microsoft Windows ターミナルサービスのライセンスは含まれていません。Microsoft オペレーティングシステム製品で提供されるターミナルサーバー機能にアクセスするには、該当する製品を使用するための追加ライセンスを購入する必要があります。使用している Microsoft オペレーティングシステム製品のライセンス契約書を参照して、入手する必要のあるライセンスを確認してください。
ターミナルサービスのライセンス管理は、クライアントアクセスライセンス (CAL) を使用して行います。CAL は、クライアントに Windows ターミナルサーバーへのアクセスを許可するライセンスです。ライセンスモードに応じて、クライアントは「ユーザー」、「デバイス」、またはその両方の組み合わせになります。
Microsoft Windows ターミナルサービスのクライアントライセンス管理は、クライアントプラットフォームによって次のように異なります。
Windows プラットフォーム - ターミナルサーバーに接続するクライアントデバイスの CAL は、Microsoft のポリシーに基づいて割り当てられます。CAL はクライアントデバイスの Windows レジストリに保存されます。
UNIX、Linux、または Mac OS X プラットフォーム - ターミナルサーバーに接続するクライアントデバイスの CAL は、SGD サーバーのデータストアのライセンスプールに保存されます。このライセンスプールの管理は、SGD 管理者が tscal コマンドを使用して行います。CAL をコマンド行から管理する を参照してください。
各 SGD サーバーには、CA 証明書トラストストアとクライアント証明書ストアという 2 つの証明書ストアがあります。
各 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 証明書のインポートが必要になることがあります。
SOAP 接続 - SOAP 接続に HTTPS が使用されている場合で、アレイ内のいずれかの SGD サーバーの証明書がサポートされていない CA または中間 CA によって署名されているとき。
SGD サーバーへの SOAP 接続の保護を参照してください。
Active Directory 認証 - Active Directory に対して SSL 接続が使用されている場合で、Active Directory サーバーの証明書がサポートされていない CA または中間 CA によって署名されているとき。
Active Directory への SSL 接続を設定する方法を参照してください。
LDAP 認証 - LDAP ディレクトリに対して SSL 接続が使用されている場合で、LDAP ディレクトリサーバーの証明書がサポートされていない CA または中間 CA によって署名されているとき。
LDAP 認証を有効にする方法を参照してください。
tarantella security customca コマンドを使用して CA 証明書または CA 証明書チェーンをインストールすると、CA 証明書は CA 証明書トラストストアにもインポートされます。これが行われるのは、このコマンドを実行した SGD サーバー上だけです。
CA 証明書を手動でインポートするには、keytool アプリケーションを使用します。keytool アプリケーションの使用方法の詳細については、「JDK Tools and Utilities」を参照してください。SGD ホストの /opt/tarantella/var/tsp/ca.pem ファイルには、CA 証明書または証明書チェーンが格納されています。
CA 証明書チェーンをインポートする必要がある場合は、チェーン内の各証明書を個別にインポートしてください。
各 SGD サーバーには、独自のクライアント証明書ストアがあります。これは /opt/tarantella/var/info/certs/sslkeystore ファイルです。
クライアント証明書ストアには、SGD サーバーが別のサーバーに接続する際に自身の識別に使用する、クライアント証明書が格納されます。
サーバーのクライアント証明書の作成とインストールには keytool アプリケーションを使用します。keytool アプリケーションの使用方法については、「JDK Tools and Utilities」を参照してください。
クライアント証明書ストアに対して証明書の追加または削除を行うときは、パスワードを入力する必要があります。クライアント証明書ストアのパスワードは SGD ごとに固有で、/opt/tarantella/var/info/key ファイル内にあります。-storepass および -keypass オプションの両方で、このパスワードを使用します。
# /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)" |
# /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 |
# /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 の標準のインストールディレクトリは、/opt/tarantella です。
SGD のインストール中に別のインストールディレクトリを指定することもできます。
インストールディレクトリをコマンド行から調べることができます。次の手順を実行します。
Solaris OS プラットフォームの場合 - 次のコマンドを使用します。
$ pkgparam `pkginfo 'tta.*' | cut -d' ' -f2` INSTDIR |
Linux プラットフォームの場合 - 次のコマンドを使用します。
$ rpm -qi tta | grep Relocations |
SGD のインストールディレクトリには、次のサブディレクトリが含まれています。
以降の節では、これらの各サブディレクトリに含まれている内容と、それらの使用目的について説明します。
SGD インストールのバックアップと復元も参照してください。
etc ディレクトリには、SGD の動作や SGD を使って表示したアプリケーションの動作を制御する構成ファイルが格納されています。次の表に示すサブディレクトリが含まれています。
サブディレクトリ | 目次 |
---|---|
etc/data | 構成ファイルは下記のとおりです。 |
etc/data/keymaps | キーボードマップファイル。 |
etc/fonts | X Window System フォントと SGD にインストールされる追加フォント。 |
etc/pkg | インストールされている SGD パッケージに関する情報 (バージョンの互換性や依存関係など)。 |
etc/templates | etc/data ディレクトリと var/serverresources ディレクトリにインストールされた標準ファイルの完全なコピー。 |
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 ディレクトリには、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 インストールを復元したり、一部の SGD コンポーネントを個別に修復したりするには、フルバックアップが必要になります。
バックアップを作成しているときに、コマンド行ツールを実行したり、Administration Console を使用したりしないでください。バックアップを作成しているときは、SGD サーバーをシャットダウンすることをお勧めします。シャットダウンできない場合は、サーバーの負荷が少ないときにバックアップを実行してください。
# tarantella archive |
アレイ内の各 SGD サーバーで、SGD インストールディレクトリ全体をバックアップします。
SGD インストールディレクトリの詳細は、SGD のインストールについて を参照してください。
SGD では、次の構成ファイルも使用されます。これらのファイルについては、使用しているファイルのうち、変更を加えたものだけをバックアップするだけでかまいません。
損傷したインストールを復元するために、SGD を次のコンポーネントに分けることができます。
続く節では、これらの各コンポーネントをバックアップする方法について説明します。
バイナリファイル、スクリプトファイル、およびテンプレートファイルが変更されるのは、インストール、パッチ、またはカスタマイズ作業のときだけです。これらのファイルが変更されることはあまりありません。
ログインスクリプトは、SGD とアプリケーションサーバーの間の対話 (たとえば、ユーザーのログイン) を制御するファイルです。ログインスクリプトを参照してください。
ログインスクリプトの復元方法は、カスタマイズしたログインスクリプトを使用しているかどうかに応じて異なります。
カスタマイズしたログインスクリプトを使用していない場合は、再インストール、バックアップ、または /opt/tarantella/etc/templates ディレクトリから復元できます。
カスタマイズしたログインスクリプトを使用している場合は、バックアップを使用して復元する必要があります。
ログインスクリプトは、/opt/tarantella/var/serverresources/expect ディレクトリにあります。
サーバー設定とは、サーバー DNS 名やサーバー調整など、SGD サーバーのプロパティーのうち、アレイのほかの SGD サーバーと共有されないすべてのプロパティーのことです。
この設定は特定の SGD ホストに固有なので、そのホストから作成したバックアップから復元する必要があります。
サーバー固有の設定は、/opt/tarantella/var/serverconfig/local ディレクトリにあります。
グローバル設定とは、他のアレイメンバーの名前など、アレイ内のすべての SGD サーバーに共通のプロパティーすべてのことです。
SGD サーバーのグローバル設定を復元するには、プライマリ SGD サーバーのバックアップから復元する必要があります。
グローバル設定は、/opt/tarantella/var/serverconfig/global ディレクトリにあります。
ローカルリポジトリ (旧称 ENS (Enterprise Naming Scheme)) は、アレイ内のすべての SGD サーバーで共有されます。ローカルリポジトリは、ユーザー、アプリケーション、およびアプリケーションサーバーに関するすべての情報を含む組織階層になります。これらの情報は、非常に頻繁に変更されます。
デフォルトでは、毎週日曜日の午前 4 時に cron ジョブを使用して、ログファイルのアーカイブが作成されます。
root ユーザーの crontab が破壊したり、アーカイブが実行されなかったりした場合は、tarantella setup コマンドを使用してデフォルト設定を復元するか、アーカイブの実行日時を変更します。
SGD をインストールすると、SGD プリンタキューが設定されます。
プリンタキューが存在しない場合、次のいずれかの方法で復元できます。
SGD プリンタキューのインストールスクリプト prtinstall.en.sh を使用します。SGD プリンタキューインストールスクリプトを参照してください。
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 ディレクトリにあります。
損傷した SGD コンポーネントを復元できない場合、またはシステムがどの程度損傷しているかわからない場合は、SGD インストールを完全に復元する必要があります。
完全な復元を実行するには、フルバックアップが必要です。SGD インストールのバックアップ方法の詳細については、SGD インストールのフルバックアップを作成する方法 を参照してください。
SGD サーバーにログインしているユーザーがいないことと、中断しているアプリケーションセッションも含め、SGD サーバー上で実行されているアプリケーションセッションがないことを確認します。
# tarantella uninstall --purge |
注 - これに失敗した場合、手動で SGD パッケージを削除しなければならないかもしれません。Linux プラットフォームでは rpm -e tta コマンド、Solaris OS プラットフォームでは pkgrm tta コマンドで削除してください。 |
# rm -rf /opt/tarantella |
# rm -rf /opt/tarantella |
注 - 必ずサーバーのバックアップから復元してください。また、ホストの DNS 名が変更されていないことを確認してください。 |
この節では、SGD サーバーの使用時に発生する一般的な問題、およびその解決方法について説明します。
ここで説明するトラブルシューティングの内容は次のとおりです。
アプリケーションの負荷分散を「最小 CPU 使用量」方式および「最大空きメモリー」方式で行うときに問題が発生する場合には、問題の理解に役立つ情報を次の場所から入手できます。
Administration Console の「グローバル設定」 → 「監視」タブで、「ログフィルタ」フィールドに次のフィルタを追加します。
server/tier3loadbalancing/*:t3loadbal%%PID%%.log server/tier3loadbalancing/*:t3loadbal%%PID%%.jsl
アプリケーションを実行するアプリケーションサーバーがどのように決定されたか、およびそのアプリケーションサーバーから送信されるデータに関する詳細な情報を入手できます。
UNIX または Linux プラットフォームのアプリケーションサーバーの場合、これらは /opt/tta_tem/var/log/tier3loadprobePID_error.log ファイルにあります。
負荷分散サービス接続 CGI (Common Gateway Interface) プログラム
http://applicationserver:3579?get&ttalbinfo という URL にアクセスします。
これらの情報を使用して、次の一般的な問題をトラブルシューティングできます。
負荷分散サービスが動作していないと考えられる場合は、次の点を確認してください。
SGD 拡張モジュールがインストールされていて、動作していますか。
Microsoft Windows アプリケーションサーバーの場合は、「コントロール パネル」 → 「管理ツール」 → 「サービス」を使用して、「Tarantella Load Balancing Service」が表示され開始されていることを確認します。
UNIX および Linux プラットフォームのアプリケーションサーバーの場合は、次のコマンドをスーパーユーザー (root) として実行して、負荷分散プロセスが稼働していることを確認します。
# /opt/tta_tem/bin/tem status |
プライマリ SGD サーバーは動作していますか。
アプリケーションサーバー上の負荷分散サービスは、負荷情報をプライマリ SGD サーバーに送信します。プライマリを使用できない場合は、アプリケーションサーバーの負荷分散方式として「最少アプリケーションセッション数」が使用されます。
ログファイルにはどのようなログが記録されていますか。
ログファイルで詳細情報を確認します。詳細については、Advanced Load Management に関するトラブルシューティング を参照してください。
アプリケーションサーバーの負荷分散プロパティーファイルを作成したあとで、プライマリ SGD サーバーをウォームリスタートする必要があります。次のコマンドをスーパーユーザー (root) として実行してください。
# tarantella restart --warm |
SGD サーバーにログインしているユーザーがいないことと、中断しているアプリケーションセッションも含め、SGD サーバー上で実行されているアプリケーションセッションがないことを確認します。
アプリケーションを実行するサーバーとして、アプリケーションサーバーの 1 つが一度も選択されない場合は、次の点を確認してください。
そのアプリケーションサーバーを使用してアプリケーションを実行できますか。
Administration Console でアプリケーションサーバーオブジェクトを確認します。アプリケーションサーバーオブジェクトの「一般」タブの「アプリケーション起動」チェックボックスが選択されていることを確認します。
ログファイルにはどのようなログが記録されていますか。
ログファイルで詳細情報を確認します。詳細については、Advanced Load Management に関するトラブルシューティングを参照してください。
アプリケーションを実行するサーバーとして、アプリケーションサーバーの 1 つが負荷に関係なく常に選択される場合は、次の点を確認してください。
ほかのアプリケーションサーバーをアプリケーションの実行に使用できますか。
Administration Console でアプリケーションサーバーオブジェクトを確認します。「一般」タブの「アプリケーション起動」チェックボックスが選択されていることを確認します。
適切な負荷分散方式が選択されていますか。
Administration Console で、アプリケーションオブジェクトの「パフォーマンス」タブか、「グローバル設定」 → 「パフォーマンス」タブで、負荷分散方式として「最大空きメモリー」または「最小 CPU 使用量」のいずれかが選択されていることを確認します。
サーバーアフィニティーを使用していますか。
サーバーアフィニティーとは、ユーザーが最後に起動したアプリケーションと同じアプリケーションサーバー上で、アプリケーションを起動しようとすることです。サーバーアフィニティーは、デフォルトで有効になっています。サーバーアフィニティー を参照してください。
ログファイルにはどのようなログが記録されていますか。
ログファイルで詳細情報を確認します。詳細については、Advanced Load Management に関するトラブルシューティングを参照してください。
サーバー負荷係数値がどちらのサーバーも同じであることを確認します。アプリケーションサーバーの相対的な処理能力を参照してください。
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 |
ファイアウォール越えモード時にユーザーが 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 のユーザーセッションの詳細については、セッション を参照してください。
Copyright © 2008, Sun Microsystems, Inc. All rights reserved