IBM Sametime Unified Telephony 9: インストール

Sametime ユーザーに統合コール機能を提供するために、IBM® Sametime® Unified Telephony 9 サーバーをインストールします。

インストール

IBM Sametime Unified Telephony 用のハードウェアとソフトウェアをインストールします。

このタスクについて

以下のタスクを順番に実行することにより、Sametime Unified Telephony をインストールします。

ハードウェアのインストール

テレフォニー制御サーバーとテレフォニーアプリケーションサーバーに関連するハードウェアの技術情報です。

仮想テレフォニー制御サーバー向けのハードウェアのセットアップ

仮想テレフォニー制御サーバーをホストする物理サーバーを構成します。

このタスクについて

仮想化されたデプロイメントはハードウェアに依存しないため、物理サーバーを構成するための固有の手順はありません。ただし、VMware を使用するには、サーバーが一連の特定の要件を満たしている必要があります。VMware ESXi 4.0 の仮想マシンをホストする物理サーバーの必須構成の詳細については、仮想化されたテレフォニー制御サーバーの要件セクション内のトピックを参照してください。

テレフォニーアプリケーションサーバー向けのハードウェアのセットアップ

テレフォニーアプリケーションサーバーのハードウェアをセットアップするためのステップは、物理的なサーバーをインストールしているか、仮想マシンをインストールしているかによって異なります。

仮想テレフォニーアプリケーションサーバー向けのハードウェアのセットアップ

仮想テレフォニーアプリケーションサーバーをホストする物理サーバーを構成します。

このタスクについて

仮想化されたデプロイメントはハードウェアに依存しないため、物理サーバーを構成するための固有の手順はありません。ただし、VMware を使用するには、サーバーが一連の特定の要件を満たしている必要があります。VMware ESXi 4 以上の仮想マシンをホストする物理サーバーの必須構成の詳細については、仮想化されたテレフォニーアプリケーションサーバーの要件セクション内のトピックを参照してください。

大規模な仮想化デプロイメントで最良のパフォーマンスを実現するには、テレフォニーアプリケーションサーバー用に 4 個以上の vCPU と 10 GB 以上の RAM、Media Server 用に 8 個以上の vCPU と 10 GB 以上の RAM を、それぞれ仮想マシンで提供する必要があります。ハイパースレッドが CPU 上で使用不可になっている必要があります。

テレフォニーアプリケーションサーバーと Media Server では、どちらも 64 ビットの Linux が必要になります。大規模なデプロイメント環境 (1 台のテレフォニーアプリケーションサーバー 5000 人を超えるユーザー) では、DaemonConfig.xml ファイルの FrameworkContainer 値を次のように変更することで、パフォーマンスを向上させることができます。

-Xms2432m -Xmx2432m -Xmn256m -Xmo2176m
物理テレフォニーアプリケーションサーバー向けのハードウェアのセットアップ

IBM Sametime Unified Telephony のデプロイメント環境で、テレフォニーアプリケーションサーバーに必要なハードウェアをセットアップします。

テレフォニーアプリケーションサーバーは、SuSE Linux オペレーティングシステムを使用する IBM System x® 上で実行されます。技術的な仕様については、Sametime Unified Telephony のシステム要件を参照してください。

テレフォニーアプリケーションサーバーハードウェアのインストールのチェックリスト

このセクションでは、テレフォニーアプリケーションサーバーのすべてのハードウェア要件のリストを示します。

ハードウェアチェックリスト

テレフォニーアプリケーションサーバーのハードウェアのチェックリストは、以下のとおりです。

  • ハードウェアの品目を確認し、ハードウェアを点検します。
  • サーバーの印刷済み資料とデジタルメディアを探します。
  • 電源オンテストを実行します。
  • ラックにスライドを取り付け、サーバーをスライド上に配置します。
  • 6 本のケーブルをすべて接続します。SCSI RAID 構成を変更します。
  • サーバー BIOS 設定を変更します。
  • Web ブラウザを通じてリモートコンソール起動を実行します。
  • IBM x3550 M4 のフルハイト PCI スロットに RAID カードが装着されていることを確認します。
テレフォニーアプリケーションサーバーのケーブル接続

このセクションでは、テレフォニーアプリケーションサーバーのケーブル接続について説明します。

  • AC または DC の電源機構 2 台 (ホットスワップ可能)
  • Intel BMC を使用したリモート管理
  • ラック最適化 1U
BIOS 設定

TAS ハードウェアのインストール中に、BIOS 設定を実行する必要もあります。

始める前に

すべてのハードウェアが問題なく作動していることを確認します。Remote Management Controller (iRMC) が構成されている必要があります。

このタスクについて

起動プロセス中に F2 キーを押して、BIOS を入力することができます。

手順
  1. [ブート設定優先順位 (Boot Settings Priority)] から、[起動シーケンス (Startup Sequence)] を以下の順序に変更します。
    1. IDE - DVD ROM
    2. SCSI - RAID LUN
    3. Legacy Only
    4. Remove all other boot items (such asUSB, Floppy, PSX, network) in order to avoid other possible delays or hangs during boot.
  2. [拡張] > [IPMI] > [LAN 設定 (LAN Settings)] から、Enter キーを押します。
  3. iRMC カードを構成します。
    1. DHCP を使用不可にする。
    2. LAN ポートを [分離 (separate)] に設定します。
    3. iRMC カードの IP データを入力します。
  4. [拡張] 画面上で、[電源オン/オフ (Power On/Off)] を選択し、[Enter] キーを押します。
  5. 値が以下のとおりであることを確認します。
    1. ソフトウェア: 有効
    2. 電源ボタン: 有効
    3. 電源オンソース: BIOS 制御
    4. リモート: 有効
    5. LAN: 有効
    6. ウェイクアップタイマー: 無効
    7. ウェイクアップモード: 毎日
サポートされているネットワークトポロジー

IBM Sametime Unified Telephony デプロイメント環境内で、テレフォニーアプリケーションサーバーと IBM WebSphere Application Server が使用するネットワークインターフェースを計画します。

テレフォニーアプリケーションサーバーノードや WebSphere Application Server ノードを、(例えば、ネットワークセキュリティやデバイス管理など) テレフォニーサービスの提供以外の目的で使用する場合は、クラスタ内にある一部またはすべてのノード上で追加のネットワークインターフェースを使用することが必要になる可能性があります。追加のアダプタは、Sametime Unified Telephony 自動化ポリシーでは定義されないため、SAMP の管理対象からは完全に除外されます。ただし、この追加のネットワークインターフェースは、テレフォニーアプリケーションサーバーと WebSphere Application Server のシグナリングインターフェースが使用するサブネットとは異なるサブネット上に存在する必要があります

例 1
  • テレフォニーアプリケーションサーバーノードまたは WebSphere Application Server ノードのシグナリングは、bond0 インターフェース上で行われます。bond0 インターフェースは、サブネット A に割り当てられます。
  • 管理 LAN は、bond1 インターフェース上に構成されます。bond1 インターフェースは、bond0 インターフェースから分離した状態を維持するため、サブネット B に割り当てられます。
例 2
  • テレフォニーアプリケーションサーバーノードのシグナリングは、bond0 インターフェース上で行われます。bond0 インターフェースは、サブネット A に割り当てられます。
  • WebSphere Application Server ノードのシグナリングは、bond1 インターフェース上で行われます。bond1 インターフェースも、サブネット A に割り当てられます。bond0 と bond1 は両方ともシグナリングに使用されるため、同じサブネット上に置くことができます。
  • 管理 LAN は、bond2 インターフェース上に構成されます。bond2 インターフェースは、シグナリングインターフェースとは異なるサブネット上でホストされる必要があるため、サブネット B に割り当てられます。

この要件が存在する理由は、テレフォニーアプリケーションサーバーまたは WebSphere Application Server のシグナリングサブネットと同じ IP サブネットでは、静的に構成されたネットワークインターフェースを保持できないためです。各 IP アドレスは、カーネルルーティングテーブル内にエントリが必要となります。TAS/WAS シグナリングサブネットと同じサブネットにあるインターフェースの場合は、同じサブネットに 2 つの経路があります。(今回の例では、管理 LAN に対して) 2 番目のエントリを作成したインターフェースに障害が発生すると、このサブネットの通信は中断されます。引き続き通信可能な別のインターフェースが存在する場合でも同様です。 その結果、SAMP は、テレフォニーアプリケーションサーバー/WebSphere Application Server インターフェースを中断状態と誤って認識し、スタンバイノードへのフェイルオーバーを開始します。シグナリングインターフェースを別個のサブネット上に保持すれば、この問題は防止できます。

ネットワークに関する考慮事項

SAMP クラスタをセットアップする場合は、すべてのピアノードに同じネットワークインターフェース構成が必要になると理解することが重要です。特に、以下の点に注意してください。

  • テレフォニーアプリケーションサーバーまたは WebSphere Application Server のシグナリングが bond0 上で行われる場合は、クラスタ内にあるすべてのノードに bond0 インターフェースが必要です。
  • テレフォニーアプリケーションサーバーのシグナリングが bond0 上で行われ、 WebSphere Application Server のシグナリングが bond1 上で行われる場合は、クラスタ内にあるすべてのノードに、bond0 インターフェースと bond1 インターフェースの両方 が必要です。
  • (例えば、ネットワークセキュリティ上の目的で) 追加のインターフェースが必要な場合、このインターフェースは、テレフォニーアプリケーションサーバーと WebSphere Application Server が使用するサブネットとは異なるサブネット上に存在する必要があります
ボンディングアダプタ

TAS および Media Server システムの SUT クラスタは、高度に使用可能であることを目的としています。このクラスタは、Tivoli System Automation for Multiplatforms という名前のクラスタフェイルオーバーソフトウェア上にインストールされます。このクラスタフェイルオーバーソフトウェアについては、[TAS ソフトウェアのインストール (Installation of TAS Software)] セクションで詳細に説明します。 信頼性を考慮して、TAS マシンのネットワークポートに冗長性を追加する必要があります。フェイルオーバー構成では、2 つのイーサネットインターフェース (eth0 および eth1) を使用する bond インターフェース (bond0) を作成する必要があります。

このタスクについて
フェイルオーバー構成では、TAS マシンには以下のインターフェースが必要です。
  • TAS と WebSphere Application Server が同じ NIC 上に存在する場合は、2 つのイーサネットインターフェース
  • TAS と WebSphere Application Server が別々の NIC 上に存在する場合は、4 つのイーサネットインターフェース
  • すべてのイーサネットインターフェースが同じサブネット上に存在する必要がある
ネットワークスイッチ、アダプタ、ケーブルの障害によるフェイルオーバー条件の可能性を減らすために、ボンディングアダプタを使用して、2 つ以上のアダプタを結び付けることができます。
手順
  1. SLES 10 SP3 上の SUT に対してボンディングアダプタを構成するには、/etc/sysconfig/network ディレクトリ内の ifcfg スクリプトを変更します。 デフォルトでは、ifcfg-eth-id-mac_address 形式のファイルが少なくとも 1 つ存在します。 例:
    Default Network Configuration File Names
    tasnode1:/etc/sysconfig/network # ls -al ifcfg-eth*
    -rw-r--r-- 1 root root 211 May 17 09:00 ifcfg-eth-id-00:1a:64:62:47:d2
    -rw-r--r-- 1 root root 211 May 17 09:00 ifcfg-eth-id-00:1a:64:62:47:d3
  2. 構成を単純にするには、ifcfg-eth-id-<mac_address> ファイルを、インターフェース名と一致する形式に名前変更します。適切な名前を決定するには、ifconfig -a を実行し、その出力を使用して、インターフェース名と mac アドレス (HWaddr) を相互に関連付けます。 ifconfig -a の出力例を以下に示します。 ifcfg-eth-id-00:1a:64:62:47:d2ifcfg-eth0 に、ifcfg-eth-id-00:1a:64:62:47:d3ifcfg-eth1 にそれぞれ名前変更します。
    Network Interface List
    tasnode1:/etc/sysconfig/network # ifconfig -a | more
    eth0      Link encap:Ethernet  HWaddr 00:1F:34:12:57:E2  
              inet addr:19.142.227.17  Bcast:19.142.227.255  Mask:255.255.252.0
              inet6 addr: fe80::21a:64ff:fe62:47d2/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:14532939 errors:0 dropped:0 overruns:0 frame:0
              TX packets:127637196 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:2175565080 (2074.7 Mb)  TX bytes:655615846 (625.2 Mb)
              Interrupt:90 
    
    eth1      Link encap:Ethernet  HWaddr 00:1A:64:62:47:D3  
              BROADCAST MULTICAST  MTU:1500  Metric:1
              RX packets:0 errors:0 dropped:0 overruns:0 frame:0
              TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
              Interrupt:98
  3. ifcfg-eth ファイルをボンディング用に適宜変更します。ifcfg-eth0 のオリジナル構成は、次の例のようになっています。
    Default ifcfg File (ifcfg-eth0)
    BROADCAST=''
    ETHTOOL_OPTIONS=''
    MTU=''
    NAME=''
    NETWORK=''
    STARTMODE='onboot'
    UNIQUE='rBUF.OxfKyHLVUp6'
    USERCONTROL='no'
    _nm_name='bus-pci-0000:02:01.0'
    BOOTPROTO=static
    IPADDR=19.142.227.17
    NETMASK=255.255.252.0
  4. アダプタがボンディングスレーブとして機能するためは、構成ファイルを変更する必要があります。具体的には、STARTMODE、BOOTPROTO、IPADDR、NETMASK、MASTER、SLAVE プロパティを変更します。ifcfg-eth0ifcfg-eth1 の両方に対して以下の変更を行ってください。
    1. [STARTMODE][Off] に設定します。
    2. [BOOTPROTO][None] に設定します。
    3. [IPADDR] を削除します。
    4. [NETMASK] を削除します。
    5. [MASTER='bond0'] を追加します。
    6. [SLAVE='yes'] を追加します。
  5. ボンディングインターフェースを作成し、物理アダプタをスレーブとして関連付けます。ifcfg-bond0 というファイルを作成します。 次の例はそのままコピーできますが、以下の例外があります。
    1. [IPADDR][NETMASK] を必要に応じて更新します。
    2. bond ペアに含まれる物理アダプタごとに [BONDING_SLAVEx] を組み込みます。
    3. [サービスネットワークの再始動 (service network restart)] を実行して、構成をアクティブにします。この手順が完了すると、いずれかのネットワークで単独に障害が発生した場合でも、ネットワーク接続が中断されません。
    Bonding Adapter (ifcfg-bond0)
    BONDING_MASTER='yes'
    BONDING_MODULE_OPTS='mode=1 miimon=100 primary=eth0'
    BOOTPROTO='static'
    BROADCAST=''
    ETHTOOL_OPTIONS=''
    IPADDR='19.142.227.17'
    MTU=''
    NAME=''
    NETMASK='255.255.252.0'
    NETWORK=''
    REMOTE_IPADDR=''
    STARTMODE='auto'
    USERCONTROL='no'
    BONDING_SLAVE0='eth0'
    BONDING_SLAVE1='eth1'
RAID 装置セットアップ

TAS ハードウェアのインストール中に、SCSI RAID を構成し、ディスクミラーを作成する必要があります。

始める前に
BIOS をセットアップしておく必要があります。
このタスクについて
以下のように、SCSI RAID 装置を構成し、ディスクミラーを作成する必要があります。
手順
  1. サーバーの電源を入れます。 システム情報を表示する多数の画面の後で、LSI バナーが表示され、LSI コントローラが初期化中であることが示されます。
    LSI Logic Corp. MPT SAS BIOS
    MPTBIOS-6.12.00.00 (2006.10.31)
    Copyright 2000-2006 LSI Logic Corp.
    Initializing ............
  2. 初期化が完了した後で、システムにより、以下のメッセージが表示されます。
    LSI Logic Corp. MPT SAS BIOS
    MPTBIOS-6.12.00.00 (2006.10.31)
    Copyright 2000-2006 LSI Logic Corp.
    Press Ctrl-C to start LSI Logic Configuration Utility...
  3. CTRL+C キーを押します。 LSI ロジックユーティリティ画面が表示されます。
  4. [Enter] キーを押して、内部コントローラ (SAS1068) を選択します。
  5. 下矢印キーを押して、RAID プロパティを選択します。[Enter] キーを押します。
  6. [IM ボリュームの作成 (Create IM Volume)] を選択し、[Enter] キーを押して、アレイを作成します。
  7. 右矢印キーを使用して、Slot Num 0 内の RAID ディスクを選択します。
  8. + (正符号) キーを押して、アレイ内に配置するドライブを選択します。
  9. D キーを押して、すべての既存のデータを上書きし、IM アレイを作成します。最初のドライブが選択されます。
  10. 下矢印キーを使用して、Slot Num 1 内の RAID ディスクを選択します。
  11. + (正符号) キーを押して、アレイの 2 番目のドライブを選択し、C キーを押して、アレイを作成します。
  12. システムプロンプトで、新規アレイを作成および保存します。
  13. 下矢印キーを使用して、変更の [保存] オプションを選択します。次に、このメニューを終了し、[Enter] キーを押します。
  14. システムが要求を処理します。これには、最大で 1 分かかることがあります。
  15. Esc キーを押して、[アダプタプロパティ (Adapter Properties)] メニューを終了します。[アダプタリストグローバルプロパティ (Adapter List Global Properties)] が表示されます。Esc キーを押して、この画面を終了します。
  16. [構成ユーティリティの終了およびリブート (Exit the Configuration Utility and Reboot)]] オプションを選択し、[Enter] キーを押して、RAID 構成を終了します。システムリブートの後で、システムにより、単一の論理ボリュームが作成されたことを示す画面が表示されます。
リモートコンソールの起動

Web ブラウザを通じてリモートコンソールを起動できます。

始める前に
テレフォニーアプリケーションサーバーの BIOS および RAID アレイをセットアップします。
このタスクについて
Web ブラウザを使用して、リモートコンソールにログオンします。ビデオのリダイレクトを使用して、コンソールをテストします。
手順
  1. LAN 設定の BIOS 内で入力した IP アドレスを使用して、Web ブラウザを通じて [リモートコンソール (Remote Console)] にログオンします。
  2. 表示されるすべての証明書警告を承認し、次のようにユーザー名とパスワードを入力します。USERID/PASSW0RD (0 はゼロです。)
  3. [サーバー管理情報 (Server Management Information)] 画面が表示されます。ナビゲーションリストで、[サーバー管理 (Server Management)] を選択し、次に [ビデオリダイレクト (Video Redirection)] を選択します。
  4. ボタンを使用して、ビデオのリダイレクトを開始します。
  5. [OK] をクリックして、表示されるすべての証明書警告を承認し、他のすべてのメッセージを承認します。
  6. 最後に、コンソールメッセージを反映する同様の画面が表示されます。
  7. 終了するには、[追加 (Extra)] メニューから [終了] を選択し、[OK] をクリックします。
次のタスク

これでテレフォニーアプリケーションサーバーのハードウェアの準備が完了しました。「SAN (ストレージエリアネットワーク) システムのハードウェアのセットアップ」に進みます。

ストレージエリアネットワーク向けのハードウェアのセットアップ

SAN (Storage Area Network) のハードウェアをセットアップするためのステップは、物理的な SAN をインストールしているか 仮想 SAN をインストールしているかによって異なります。

仮想ストレージエリアネットワーク向けのハードウェアのセットアップ

仮想デプロイメント用の SAN (ストレージエリアネットワーク) として機能する物理ハード・ディスクを構成します。

このタスクについて

ここでは、テレフォニーアプリケーションサーバーとして機能する 2 台の仮想マシンが「VM_TAS1」と「VM_TAS2」という名前で既にセットアップされていると仮定します。 以下の手順に従い、VM_TAS1 をホストする物理サーバー上にディスクをセットアップし、そのディスクを VM_TAS2 と共有できるようにします。これにより、このディスクをデプロイメント用の SAN として機能させることができます。

手順
  1. VM_TAS1 で、以下の設定を持つ新規ディスクを作成します。
    • [クラスタ機能のサポート (Support for clustering features)] を有効にします。
    • モードを [独立 - 永続] に設定します。
    • ディスクをホストする新規 SCSI コントローラとして [SCSI 1:0] を使用します。
  2. VM_TAS1 で、仮想マシンのハードウェア設定に移動し、新規 SCSI コントローラを更新して、SCSI バス共有を [物理] に設定します。
  3. VM_TAS2 のハードウェア設定で、上記手順で VM_TAS1 マシン上に作成したディスクを以下のように追加します。
    1. [既存を追加 (Add an existing)] オプションを使用します。
    2. VM_TAS1 用に作成したディスクを表示します。
    3. そのディスクを、VM_TAS1 の場合と同様に SCSI 1:0 コントローラに追加します。
    4. 以下の手順により、VM_TAS1 用に選択したものと同じ SCSI 設定を選択します。
      • [クラスタ機能のサポート (Support for clustering features)] を有効にします。
      • モードを [独立 - 永続] に設定します。
物理ストレージエリアネットワーク向けのハードウェアのセットアップ

この文書では、SAN (ストレージエリアネットワーク) システム — IBM DS3400 のセットアップを中心に説明します。この文書では、複数のテレフォニーアプリケーションサーバーシステムと単一のスタンバイ/フェイルオーバーサーバーから成る環境の例についても説明します。SAN は、この環境のハード要件です。

頭字語/用語:

  • FC: ファイバーチャネル: ストレージネットワーキングへのアクセスに使用されるギガビット高速ネットワークテクノロジ。対より線または光ファイバーのいずれかを使用できます。
  • SAN: ストレージエリアネットワーク。FC を使用してアクセスされるディスクアレイ。
  • HBA: ホストバスアダプタ: FC を使用して SAN または SAN スイッチにアクセスするためにホスト内にインストールされる PCI カード。
  • アレイ: 論理的にグループ化され、特定の RAID レベルに関連付けられる一連のディスクドライブ。
  • 論理ドライブ: ホストがディスクアレイの割り振り済み部分にアクセスするために作成される仮想コンポーネント。
  • LUN: 論理装置番号: アクセスするホストが認識する論理ドライブ ID。
ハードウェア

このセットアップに関連するハードウェアコンポーネントは、トポロジのテレフォニーアプリケーションサーバーおよび SAN 部分に焦点を当てています。Sametime サーバーまたはテレフォニー制御サーバーの詳細は含まれません。これらのコンポーネントは変更されず、テレフォニーアプリケーションサーバーおよび SAN から独立しています。以下の表は、この文書を通してそれぞれの例で使用されるハードウェアコンポーネントおよび参照ホスト名を示しています。

コンポーネント タイプ/モデル タイプ/モデル
TAS_1 IBM xSeries 3550 M3 stx3455d
TAS_2 IBM xSeries 3550 M3 stx3455e
TAS_3 IBM xSeries 3550 M3 stx3455f
TAS_4 IBM xSeries 3550 M3 stx3455g
TAS_5 IBM xSeries 3550 M3 stx3455h
SAN ディスクシステム IBM DS3400 N/A
24 ポート SAN スイッチ IBM SAN 24B-4 N/A
アーキテクチャ概要
論理マッピング
以下の図は、フェイルオーバー環境における IBM Sametime Unified Telephony のアーキテクチャ全体の詳細を示しています。HBA カードは、スタンバイシステムを含むすべてのテレフォニーアプリケーションサーバーシステム上にインストールされます。これにより、テレフォニーアプリケーションサーバーシステムは、SAN スイッチを持つ SAN に接続できます。
注: クラスタソフトウェア SAMP は、この図に含まれていません。クラスタソフトウェアがこのトポロジと相互作用する方法を含むデプロイメントの詳細については、以降の各セクションで説明します。このセクションの主な目的は、SAN がどのように使用されるかを説明することです。
論理マッピング
SAN LUN の構成:

以下の図は、ホスト/パーティションから SAN LUN への論理マッピングの例を示しています。SAN は複数の論理ディスクアレイに分割されます。テレフォニーアプリケーションサーバーのサーバー上の HBA (ホストバスアダプタ) カードは、標準 SATA ドライブマッピング (sda および sdb など) を使用して、これらの論理ディスクアレイにアクセスします。以下の表は、ホストから LUN へのマッピングの例と共に、それに関連付けられたアレイ割り振りを示しています。例えば、ホスト stx3455b 上にあるテレフォニーアプリケーションサーバーは、SATA ドライブ sdb を使用して、/enterprise ディレクトリをマウントします。これは、SAN 上の LUN 0にマップされます。

SAN LUN の表

アクティブおよびスタンドバイのテレフォニーアプリケーションサーバーシステムは、以下の方法で SAN LUN と相互作用します。

アクティブシステムおよびスタンバイシステムの LUN 相互作用図
各システムへの論理マッピングを提供することで、スタンバイシステムはクラスタ内の任意のシステムを引き継ぐことができます。
注: すべてのシステムは、すべての論理マッピングを維持します。障害が発生したシステムをスタンバイシステムが引き継ぐ場合、障害が発生したシステムが (オペレーティングシステムのパッチを適用するなどして) 修復されると、元のアクティブノードが代理のスタンバイノードになります。

SAN は、ストレージマネージャと呼ばれるユーティリティを使用して構成されます。ストレージマネージャは、アレイおよび論理ドライブを構成するための単純なインターフェースです。 ストレージマネージャユーティリティを使用して、新規論理ドライブを作成し、論理ドライブを命名し、論理ドライブ名から LUN へのマッピングを表示します。単純化するために、すべてのテレフォニーアプリケーションサーバーを含む 1 つのホストグループを持つ SAN を構成できます。これにより、すべてのテレフォニーアプリケーションサーバーがすべての LUN にアクセスできます。この構成では、適切なマシンから適切な LUN をマウントします。以下の図は、アレイ割り振りの例および関連するホストグループを示しています。

アレイ割り振りの表
QLogic HBA (ホストバスアダプタ) のインストール

以下の手順では、IBM Sametime Unified Telephony デプロイメントで、Qlogic 4 Gb FC single-port PCIe HBA for SystemX アダプタをインストールする方法について説明します。

手順
  1. HBA カードをテレフォニーアプリケーションサーバーの空の PCI スロットに挿入します。
  2. システムを最新の RPM に更新します。
  3. アクティブカーネルが有効な非デバッグカーネルであること、およびドライバのインストールが停止していることを確認します。
    1. 使用される SLES 10 SP3 カーネルは 2.6.16.54-0.2.8-bigsmp です。
    2. uname -a コマンドを使用して確認してください。
    3. /boot/grub/menu.lst の「デフォルト」整数 (2 行目) を更新することによりカーネルを切り替えて、リブートします。
  4. 最新の QLogic ドライバをダウンロードします。
    1. http://www.qlogic.comを参照します。
    2. [Downloads] タブをクリックします。
    3. [QLogic Models] の下にある検索ボックスで、[operating system] をクリックします。
      Qlogic の検索条件
    4. [Fibre Channel Adapters] > [Linux] > [Linux Novell SLES (32-bit)] を選択します。
    5. [Go] ボタンをクリックして検索を実行します。
    6. 結果のページで、[Drivers] の表を参照し、[2.6 Kernel Drivers] のセクションを見つけて、[SANsurfer Linux Driver Installer (x86/x64/IA64)] のリンクをクリックしてダウンロードを開始します。
      結果の表からドライバを選択する

    SANsurfer インストーラには、CLI による操作を実行するための scli が含まれています。また、このインストーラでは、HBA ドライバをインストールし、構成して、リブート時にロードするのに必要なすべてのステップが自動化されています。

  5. qlafc-linux-8.02.*-install.tgz を解凍します。
  6. 解凍ディレクトリ qlafc-linux-8.02.*-install に移動します。
  7. ./qlinstall を使用して、ドライバをインストールします。
  8. システムをリブートします。
QLogic HBA (ホストバスアダプタ) の更新

一部のシステムに付属している Qlogic HBA BIOS のレベルでは、UEFI (V1.28 など) をサポートしていません。UEFI をサポートするように HBA BIOS を更新して、起動時間を短縮します。

このタスクについて

SANSurfer アプリケーションとマルチブートイメージの両方をダウンロードし、SANSurfer を使用してイメージをインストールします。

このタスクでは、HBA BIOS を以下のバージョンに更新します。
  • 4GB BIOS バージョン: 2.02
  • 4GB FCode バージョン: 2.00
  • 4GB EFI バージョン: 2.00
  • ファームウェアバージョン: 4.03.01
手順
  1. 4GB FC アダプタの Qlogic マルチブートイメージを以下のようにしてダウンロードします。
    1. http://driverdownloads.qlogic.com/QLogicDriverDownloads_UI/ShowEula.aspx?resourceid=25334&Contentid=69579&docid=21253 をブラウズします。
    2. ページの下部にある [Agree] ボタンをクリックします。
    3. [ファイルのダウンロード] ダイアログボックスで、[保存] をクリックします。
    4. [Save As] ボックスで、ファイルの保存先にするディレクトリを選択し、[Save] をクリックします。
    5. マルチブートイメージを解凍します。

      このステップではいくつかのファイルが解凍されるため、サブディレクトリへ解凍することをお勧めします。

  2. Qlogic SANSurfer Management Application for Linux を以下のようにしてダウンロードします。
    1. http://driverdownloads.qlogic.com/QLogicDriverDownloads_UI/ShowEula.aspx?resourceid=24816&Contentid=67882&docid=19583 をブラウズします。
    2. ページの下部にある [Agree] ボタンをクリックします。
    3. [ファイルのダウンロード] ダイアログボックスで、[保存] をクリックします。
    4. [Save As] ボックスで、ファイルの保存先にするディレクトリを選択し、[Save] をクリックします。
    5. SANSurfer Management Application を解凍します。
    6. 解凍済みのファイルを実行して、SANSurfer Management Application をインストールします。
    7. [Choose a product] 画面で、[FC HBA GUI and ALL Agent] をクリックします。
      [FC HBA GUI and ALL Agent] の選択
  3. SANSurfer アプリケーションをインストールしたら、起動します。
  4. [Enter Hostname or IP Address] ボックスで、リストから [Local Host] を選択し、[Connect] ボタンをクリックします。
    ローカルホストへ接続
  5. [General Configuration Wizard] を開始するよう求められたら、[No] をクリックします。
  6. "[FC HBA]" タブにデータが読み込まれるのを待ってから、いずれかの HBA ポートを選択します。
    HBA ポートの選択
  7. [Utilities] タブをクリックし、[Update Entire Image] をクリックします。
    イメージ全体の更新
  8. [Open] ボックスで、マルチブートイメージを解凍した (ステップ 1) ディレクトリを参照し、Q24AF169.BIN を選択して、[Open] をクリックします。
    Q24AF169.BIN を参照して開く
  9. プロンプトが表示された場合は、HBA Adapter Bios のセキュリティパスワードを入力し、[OK] をクリックして先に進み、更新が完了するのを待ちます。

    デフォルトのパスワードは、「config」です (パスワードが変更されている場合は、技術サポートにお問い合わせください)。

    パスワードを入力して [OK] をクリックする
  10. [Flash Update Complete] というメッセージが表示されたら、[OK] をクリックします。
    更新が完了したら [OK] をクリックする
QLogic HBA の構成

以下の手順では、Qlogic 4 Gb FC single-port PCIe HBA for SystemX アダプタを構成する方法について説明します。

手順
  1. システムの内部 RAID から SuSE Linux を開始します。
    Qlogic アダプタを介して SAN に接続されている X3550 M2 サーバーを使用する場合は、システムの内部 RAID から SuSE Linux を起動できない可能性があります。この状況が発生した場合には、以下のブート優先順位に従って、UEFI でブートマネージャを実行中に「Legacy only」を有効にします。
    • CD/DVD Legacy only
    • Hard disk 0
    • Hard disk 1
    これで、SuSE Linux を RAID から起動できるようになりました。
  2. cat /proc/scsi/scsi を使用して、SCSI 構成を表示し、使用可能な SAN LUN を参照します。この例では、SAN LUN は scsi5 でアクセス可能です。
    SCSI Devices
    tasnode1:~ # cat /proc/scsi/scsi
    Attached devices:
    Host: scsi4 Channel: 00 Id: 00 Lun: 00
      Vendor: IBM-ESXS Model: ST373455SS       Rev: BA26
      Type:   Direct-Access                    ANSI SCSI revision: 05
    Host: scsi4 Channel: 00 Id: 01 Lun: 00
      Vendor: IBM-ESXS Model: ST373455SS       Rev: BA26
      Type:   Direct-Access                    ANSI SCSI revision: 05
    Host: scsi4 Channel: 01 Id: 00 Lun: 00
      Vendor: LSILOGIC Model: Logical Volume   Rev: 3000
      Type:   Direct-Access                    ANSI SCSI revision: 02
    Host: scsi5 Channel: 00 Id: 00 Lun: 00
      Vendor: IBM      Model: 1722-600         Rev: 0914
      Type:   Direct-Access                    ANSI SCSI revision: 05
    Host: scsi5 Channel: 00 Id: 00 Lun: 01
      Vendor: IBM      Model: 1722-600         Rev: 0914
      Type:   Direct-Access                    ANSI SCSI revision: 05
    Host: scsi5 Channel: 00 Id: 00 Lun: 02
      Vendor: IBM      Model: 1722-600         Rev: 0914
      Type:   Direct-Access                    ANSI SCSI revision: 05
    Host: scsi5 Channel: 00 Id: 00 Lun: 03
      Vendor: IBM      Model: 1722-600         Rev: 0914
      Type:   Direct-Access                    ANSI SCSI revision: 05
    Host: scsi5 Channel: 00 Id: 00 Lun: 04
      Vendor: IBM      Model: 1722-600         Rev: 0914
      Type:   Direct-Access                    ANSI SCSI revision: 05
    Host: scsi5 Channel: 00 Id: 00 Lun: 05
      Vendor: IBM      Model: 1722-600         Rev: 0914
      Type:   Direct-Access                    ANSI SCSI revision: 05
    Host: scsi5 Channel: 00 Id: 00 Lun: 31
      Vendor: IBM      Model: Universal Xport  Rev: 0914
      Type:   Direct-Access                    ANSI SCSI revision: 05
    Host: scsi6 Channel: 00 Id: 00 Lun: 00
      Vendor: AVOCENT  Model: vmDisk-CD        Rev: 0.01
      Type:   CD-ROM                           ANSI SCSI revision: 02
    Host: scsi7 Channel: 00 Id: 00 Lun: 00
      Vendor: AVOCENT  Model: vmDisk           Rev: 0.01
      Type:   Direct-Access                    ANSI SCSI revision: 02
    tasnode1:~ #
  3. SATA ドライブ ID を確認します。それには、/sys/bus/scsi/devices ディレクトリを参照し、ブロック ID block:sdX を探します。この例では、SAN は scsi5 であるため、5 で始まるデバイス ID が参照されました。各デバイスディレクトリの最後の整数は、SAN 構成に対応する LUN ID です。5:0:0:0 (LUN 0) の場合、SATA ドライブは /dev/sdb block:sdb です。 この情報を使用して、特定のシステム上に SAN ドライブをマウントする方法を決定します。
    Determine SD Identifiers
    tasnode1:~ # cd /sys/bus/scsi/devices/
    tasnode1:/sys/bus/scsi/devices # ls
    4:0:0:0  4:0:1:0  4:1:0:0  5:0:0:0  5:0:0:1  5:0:0:2  5:0:0:3  
    5:0:0:31  5:0:0:4  5:0:0:5  6:0:0:0  7:0:0:0
    tasnode1:/sys/bus/scsi/devices # ls 5¥:0¥:0¥:0
    block:sdb  delete          driver   iocounterbits  ioerr_cnt      
    model  queue_depth  rescan   rev                  scsi_disk:5:0:0:0  
    scsi_level  timeout  uevent
    bus        device_blocked  generic  iodone_cnt     iorequest_cnt  
    power  queue_type   retries  scsi_device:5:0:0:0  scsi_generic:sg3  
    state       type     vendor
    tasnode1:/sys/bus/scsi/devices # ls 5¥:0¥:0¥:1
    block:sdc  delete          driver   iocounterbits  ioerr_cnt      
    model  queue_depth  rescan   rev                  scsi_disk:5:0:0:1  
    scsi_level  timeout  uevent
    bus        device_blocked  generic  iodone_cnt     iorequest_cnt  
    power  queue_type   retries  scsi_device:5:0:0:1  scsi_generic:sg4   
    state       type     vendor
    tasnode1:/sys/bus/scsi/devices # ls 5¥:0¥:0¥:2
    block:sdd  delete          driver   iocounterbits  ioerr_cnt      
    model  queue_depth  rescan   rev                  scsi_disk:5:0:0:2  
    scsi_level  timeout  uevent
    bus        device_blocked  generic  iodone_cnt     iorequest_cnt  
    power  queue_type   retries  scsi_device:5:0:0:2  scsi_generic:sg5   
    state       type     vendor
    tasnode1:/sys/bus/scsi/devices # ls 5¥:0¥:0¥:3
    block:sde  delete          driver   iocounterbits  ioerr_cnt      
    model  queue_depth  rescan   rev                  scsi_disk:5:0:0:3  
    scsi_level  timeout  uevent
    bus        device_blocked  generic  iodone_cnt     iorequest_cnt  
    power  queue_type   retries  scsi_device:5:0:0:3  scsi_generic:sg6   
    state       type     vendor
    tasnode1:/sys/bus/scsi/devices # ls 5¥:0¥:0¥:4
    block:sdf  delete          driver   iocounterbits  ioerr_cnt      
    model  queue_depth  rescan   rev                  scsi_disk:5:0:0:4  
    scsi_level  timeout  uevent
    bus        device_blocked  generic  iodone_cnt     iorequest_cnt  
    power  queue_type   retries  scsi_device:5:0:0:4  scsi_generic:sg7   
    state       type     vendor
    tasnode1:/sys/bus/scsi/devices # ls 5¥:0¥:0¥:5
    block:sdg  delete          driver   iocounterbits  ioerr_cnt      
    model  queue_depth  rescan   rev                  scsi_disk:5:0:0:5  
    scsi_level  timeout  uevent
    bus        device_blocked  generic  iodone_cnt     iorequest_cnt  
    power  queue_type   retries  scsi_device:5:0:0:5  scsi_generic:sg8   
    state       type     vendor
    tasnode1:/sys/bus/scsi/devices #
  4. mke2fs -j /dev/sdb を使用して、各 SATA ドライブの ext3 ファイルシステムを作成します。/dev/sdb を、ステップ 2 で確認した情報に置き換えてください。ドライブごとにこの手順を繰り返します。
  5. /dev/disk/by-id を参照することにより、マウント対象として /etc/fstab ファイルで使用するディスク ID を確認します。この例では、scsi-3600a0b80000f14a900000368489ae610/dev/sdb のディスク ID です。
    tasnode1:~ # cd /dev/disk/by-id/
    tasnode1:/dev/disk/by-id # ls -al
    total 0
    drwxr-xr-x 2 root root 320 Aug  7 15:03 .
    drwxr-xr-x 5 root root 100 Aug  7 11:03 ..
    lrwxrwxrwx 1 root root   9 Aug  7 11:03 edd-int13_dev80 -> ../../sda
    lrwxrwxrwx 1 root root  10 Aug  7 11:03 edd-int13_dev80-part1 -> ../../sda1
    lrwxrwxrwx 1 root root  10 Aug  7 11:03 edd-int13_dev80-part2 -> ../../sda2
    lrwxrwxrwx 1 root root   9 Aug  7 11:03 
    scsi-3600508e00000000046b9ebfdf84b9a0a -> ../../sda
    lrwxrwxrwx 1 root root  10 Aug  7 11:03 
    scsi-3600508e00000000046b9ebfdf84b9a0a-part1 -> ../../sda1
    lrwxrwxrwx 1 root root  10 Aug  7 11:03 
    scsi-3600508e00000000046b9ebfdf84b9a0a-part2 -> ../../sda2
    lrwxrwxrwx 1 root root   9 Aug  7 11:03 
    scsi-3600a0b80000f14a900000368489ae610 -> ../../sdb
    lrwxrwxrwx 1 root root   9 Aug  7 11:03 
    scsi-3600a0b80000f14a900000373489ae660 -> ../../sdd
    lrwxrwxrwx 1 root root   9 Aug  7 11:03 
    scsi-3600a0b80000f14a90000037e489ae6a6 -> ../../sdf
    lrwxrwxrwx 1 root root   9 Aug  7 11:03 
    scsi-3600a0b80000f4d2e0000019d489ad2f1 -> ../../sdc
    lrwxrwxrwx 1 root root   9 Aug  7 11:03 
    scsi-3600a0b80000f4d2e000001a3489ad333 -> ../../sde
    lrwxrwxrwx 1 root root   9 Aug  7 11:03 
    scsi-3600a0b80000f4d2e000001a9489ad387 -> ../../sdg
    lrwxrwxrwx 1 root root   9 Aug  7 15:03 
    usb-AVOCENT_vmDisk-CD_00430009CB6 -> ../../sr0
    lrwxrwxrwx 1 root root   9 Aug  7 15:03 
    usb-AVOCENT_vmDisk_00430009CB6 -> ../../sdh
    tasnode1:/dev/disk/by-id #
    Disk Identifiers
  6. ステップ 4 で得られたディスク ID を使用して、ファイルシステム上のマウントポイントごとに fstab エントリを作成します。具体的には、/enterprise/opt/IBM/WebSphere のエントリを作成します。
    /etc/fstab Configuration
    tasnode1:~ # cat /etc/fstab
    /dev/disk/by-id/scsi-3600508e00000000046b9ebfdf84b9a0a-part2 /      
    ext3 acl,user_xattr        1 1
    proc                 /proc                proc       defaults              
    0 0
    sysfs                /sys                 sysfs      noauto                
    0 0
    debugfs              /sys/kernel/debug    debugfs    noauto                
    0 0
    usbfs                /proc/bus/usb        usbfs      noauto                
    0 0
    devpts               /dev/pts             devpts     mode=0620,gid=5       
    0 0
    /dev/sda1 swap swap defaults 0 0
    /dev/disk/by-id/scsi-3600a0b80000f14a900000368489ae610 /enterprise  
    ext3 noauto,acl,user_xattr 1 0
    /dev/disk/by-id/scsi-3600a0b80000f4d2e0000019d489ad2f1 /opt/IBM     
    ext3 noauto,acl,user_xattr 1 0
    tasnode1:~ #
  7. mount /enterprise を実行して、マウントをテストします。
MPIO (Multipath IO) に合わせた構成

IBM Sametime Unified Telephony デプロイメント環境で SAN との Multipath IO 接続をサポートするために Linux を構成します。

このタスクについて

このトピックでの使用例は、デュアルポートの Qlogic カードを備えた 3550 M2 です。2 つのポートは、2 つの異なる Dell EMC SAN スイッチに接続されています。2 つの LUN は SAN 上で構成されており、Qlogic WWN に割り当てられています。

手順
  1. root としてサーバーにログインします。
  2. SCSI デバイスを表示します。
    geatas1node2:~ # lsscsi
    [0:0:0:0]    cd/dvd  TSSTcorp CDDVDW TS-L633B  IB03  /dev/sr0
    [4:0:0:0]    disk    IBM-ESXS ST9146803SS      B536  -       
    [4:0:1:0]    disk    IBM-ESXS ST9146803SS      B536  -       
    [4:1:1:0]    disk    LSILOGIC Logical Volume   3000  /dev/sda
    [5:0:0:0]    disk    DGC      RAID 5           0428  /dev/sdb
    [5:0:0:1]    disk    DGC      RAID 5           0428  /dev/sdc
    [5:0:1:0]    disk    DGC      RAID 5           0428  /dev/sdd
    [5:0:1:1]    disk    DGC      RAID 5           0428  /dev/sde
    [6:0:0:0]    disk    DGC      RAID 5           0428  /dev/sdf
    [6:0:0:1]    disk    DGC      RAID 5           0428  /dev/sdg
    [6:0:1:0]    disk    DGC      RAID 5           0428  /dev/sdh
    [6:0:1:1]    disk    DGC      RAID 5           0428  /dev/sdi
    2 つの LUN が作成されて表示されています。LUN 0 は最下位桁の「0」で示されます。
    [5:0:0:0]
    [5:0:1:0]
    [6:0:0:0]
    [6:0:1:0]

    一方、LUN 1 は最下位桁の「1」で示されます。

    [5:0:0:1]    
    [5:0:1:1]    
    [6:0:0:1]    
    [6:0:1:1]
  3. YaST を使用してマルチパスパッケージを追加します。
  4. マルチパスドライバをブートシーケンスに挿入します。
    geatas1node2:~ # insserv multipathdgeatas1node2:~ # insserv boot.multipath
  5. ドライバを起動します。
    geatas1node2:~ # /etc/init.d/boot.multipath start
    
    Creating multipath targets done
    geatas1node2:~ multipathd start
    Starting multipathd done
  6. Multipath デーモンをコマンドモードで開始します。
    geatas1node2:~ # multipathd -k
  7. 使用可能なコマンドを表示します。
    multipathd> help
    multipath-tools v0.4.8 (08/02, 2007)
    CLI commands reference:
     list|show paths
     list|show maps|multipaths
     list|show maps|multipaths status
     list|show maps|multipaths stats
     list|show maps|multipaths topology
     list|show topology
     list|show map|multipath $map topology
     list|show config
     list|show blacklist
     list|show devices
     add path $path
     remove|del path $path
     add map|multipath $map
     remove|del map|multipath $map
     switch|switchgroup map|multipath $map group $group
     reconfigure
     suspend map|multipath $map
     resume map|multipath $map
     reinstate path $path
     fail path $path
  8. 生成されたマルチパストポロジを表示します。
    multipathd> show top
    36006016001802200b593f40ae042df11 dm-0 DGC,RAID 5
    [size=30G][features=1 queue_if_no_path][hwhandler=1 emc]
    ¥_ round-robin 0 [prio=2][active]
     ¥_ 6:0:0:1 sdg 8:96  [active][ready]
     ¥_ 5:0:0:1 sdc 8:32  [active][ready]
    ¥_ round-robin 0 [prio=0][enabled]
     ¥_ 6:0:1:1 sdi 8:128 [active][ready]
     ¥_ 5:0:1:1 sde 8:64  [active][ready]
    36006016001802200b493f40ae042df11 dm-1 DGC,RAID 5
    [size=30G][features=1 queue_if_no_path][hwhandler=1 emc]
    ¥_ round-robin 0 [prio=2][active]
     ¥_ 6:0:0:0 sdf 8:80  [active][ready]
     ¥_ 5:0:0:0 sdb 8:16  [active][ready]
    ¥_ round-robin 0 [prio=0][enabled]
     ¥_ 6:0:1:0 sdh 8:112 [active][ready]
     ¥_ 5:0:1:0 sdd 8:48  [active][ready]
    multipathd> geatas1node2:~ # 
    geatas1node2:~ # 
  9. ディスクを表示します。
    geatas1node2:~ # cd /dev/disk/by-id
    geatas1node2:/dev/disk # ls 
    
    edd-int13_dev80
    edd-int13_dev80-part1
    edd-int13_dev80-part2
    scsi-3600508e000000000a8648159e62e3106
    scsi-3600508e000000000a8648159e62e3106-part1
    scsi-3600508e000000000a8648159e62e3106-part2
    scsi-36006016001802200b493f40ae042df11
    scsi-36006016001802200b593f40ae042df11
  10. ファイルシステムを作成します。
    geatas1node2:/dev/disk # mkfs -j /dev/disk/by-id/scsi-6006016001802200b493f40ae0
    
    mke2fs 1.38 (30-Jun-2005)
    Filesystem label=
    OS type: Linux
    Block size=4096 (log=2)
    Fragment size=4096 (log=2)
    3932160 inodes, 7864320 blocks
    393216 blocks (5.00%) reserved for the super user
    First data block=0
    Maximum filesystem blocks=8388608
    240 block groups
    32768 blocks per group, 32768 fragments per group
    16384 inodes per group
    Superblock backups stored on blocks: 
    	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    	4096000
    
    Writing inode tables done                            
    Creating journal (32768 blocks): done
    Writing superblocks and filesystem accounting information: done
    
    This filesystem will be automatically checked every 36 mounts or
    180 days, whichever comes first.  Use tune2fs -c or -i to override.
    
    geatas1node2:/dev/disk # mkfs -j /dev/disk/by-id/scsi-6006016001802200b593f40ae0
    
    mke2fs 1.38 (30-Jun-2005)
    Filesystem label=
    OS type: Linux
    Block size=4096 (log=2)
    Fragment size=4096 (log=2)
    3932160 inodes, 7864320 blocks
    393216 blocks (5.00%) reserved for the super user
    First data block=0
    Maximum filesystem blocks=8388608
    240 block groups
    32768 blocks per group, 32768 fragments per group
    16384 inodes per group
    Superblock backups stored on blocks: 
    	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    	4096000
    
    Writing inode tables:   done                            
    Creating journal (32768 blocks): done
    Writing superblocks and filesystem accounting information: done
    
    This filesystem will be automatically checked every 31 mounts or
    180 days, whichever comes first.  Use tune2fs -c or -i to override.
    geatas1node2:/dev/disk # 
  11. ライブラリを作成します。
    geatas1node2:/dev/disk # cd /
    geatas1node2:/ # mkdir /enterprise
    
    geatas1node2:/ # cd /opt/
    [mgeatas1node2:/opt # mkdir IBM
    geatas1node2:/opt # cd IBM/
    geatas1node2:/opt/IBM # mkdir WebSphere
  12. マウントするディスクを表示します。
    geatas1node2:~ # mount /dev/disk/by-id/
    edd-int13_dev80
    edd-int13_dev80-part1
    edd-int13_dev80-part2
    scsi-3600508e000000000a8648159e62e3106
    scsi-3600508e000000000a8648159e62e3106-part1
    scsi-3600508e000000000a8648159e62e3106-part2
    scsi-36006016001802200b493f40ae042df11
    scsi-36006016001802200b593f40ae042df11
  13. ディスクをマウントします。
    geatas1node2:~ # mount /dev/disk/by-id/scsi-36006016001802200b493f40ae042df11 /enterprise/
    
    geatas1node2:~ # mount /dev/disk/by-id/scsi-36006016001802200b593f40ae042df11 /opt/IBM/WebSphere/
  14. マウントされたディスクを表示します。
    geatas1node2:~ # mount
    /dev/sda2 on / type reiserfs (rw,acl,user_xattr)
    proc on /proc type proc (rw)
    sysfs on /sys type sysfs (rw)
    debugfs on /sys/kernel/debug type debugfs (rw)
    udev on /dev type tmpfs (rw)
    devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
    securityfs on /sys/kernel/security type securityfs (rw)
    /dev/dm-1 on /enterprise type ext3 (rw)
    /dev/dm-0 on /opt/IBM/WebSphere type ext3 (rw)

    マウントポイントが、それらの新しい仮想名である dm-0 および dm-1 と一緒に表示されます。

  15. ファイルシステムを表示します。
    geatas1node2:~ # df
    Filesystem           1K-blocks      Used Available Use% Mounted on
    /dev/sda2            140468028  13868796 126599232  10% /
    udev                   3103544       180   3103364   1% /dev
    /dev/dm-1             30963708    176288  29214556   1% /enterprise
    /dev/dm-0             30963708    176288  29214556   1% /opt/IBM/WebSphere
    geatas1node2:~ # 
  16. 構成をさらに進めるため、通常のフェイルオーバー構成に戻します。
次のタスク

この時点で、すべてのサーバー用のハードウェアの準備が完了し、「ソフトウェアインストール」のタスクに進む準備ができました。

ソフトウェアインストール

インストールチェックリストを確認してから、TCS および TAS をインストールします。

テレフォニー制御サーバーのインストール

このセクションでは、テレフォニー制御サーバーのインストールに関する情報を提供します。

テレフォニー制御サーバーのインストールパッケージのダウンロード

テレフォニー制御サーバー用の IBM Sametime Unified Telephony インストールパッケージをダウンロードし、インストールプログラムを解凍します。

このタスクについて

テレフォニー制御サーバーは Linux オペレーティングシステムと一緒にパッケージ化されています。テレフォニー制御サーバーは DVD からインストールする必要があります。ただし、NCPE ウィザード (node.cfg ファイルの作成で使用します) の実行に使用される .iso ファイルをコンピュータに直接ダウンロードして、そこから使用することができます。

テレフォニー制御サーバーをインストールしたら、パッチを適用してパッケージ内の Linux オペレーティングシステムを更新します (オペレーティングシステムを手動で更新することはできません)。

手順
  1. 以下のいずれかの方法で、テレフォニー制御サーバーのパッケージにアクセスします。
  2. 次のコマンドを実行して、/software/IBM というディレクトリを作成します。
    mkdir /software/IBM
  3. 新しい /software/IBM ディレクトリにパッケージをコピーします。
    DVD の場合、以下のコマンドを使用します。
    cp /DVD_mount_point/file_name.iso /software/IBM
  4. その新規ディレクトリにナビゲートします。
    cd /software/IBM
  5. 最後に、次のコマンドを使用して、適切なインストーラを解凍します。
    tar xvfz file_name.tgz
パスポートアドバンテージを使用して IBM 製品をダウンロードする

IBM パスポートアドバンテージ Web サイトには、入手資格のあるすべてのソフトウェアへのアクセスが用意されています。インストールするために製品をコンピュータに直接ダウンロードでき、IBM Sametime のインストールを開始する方法を参照するために『クイックスタートガイド』をダウンロードできます。

このタスクについて

パスポートアドバンテージでは、IBMソフトウェア購入製品へのアクセスを提供しているため、インストール先にするコンピュータに製品を直接ダウンロードできます。パスポートアドバンテージプログラムの詳細については、プログラムの概要を参照してください。

パスポートアドバンテージから製品をダウンロードするには、IBM カスタマー ID が必要です。カスタマー ID をお持ちでない場合は、以下のようにしてパスポートアドバンテージのサイトに登録する必要があります。
  1. ブラウザを開き、パスポートアドバンテージのサインインページにナビゲートします。
  2. 新規のお客様登録フォームに入力します。
  3. [Register] をクリックします。
IBM カスタマー ID を受け取ったら、以下の手順での説明に従って製品のダウンロードに進みます。
手順
  1. ブラウザを開き、パスポートアドバンテージのサインインページにナビゲートします。
  2. [Customer sign in] をクリックします。
  3. お客様の IBM カスタマー ID とパスワードを入力して、[Sign in] をクリックします。
  4. [Software and services online] ページで、[Software download & media access] をクリックします。
    [Software download & media access] リンクをクリックします。
  5. [Find downloads & media] ページで、[Download finder] をクリックします。
    [Download finder] リンクをクリックします。

    Passport Advantage®には、ダウンロードの権利がある (購入した) 製品のリストが表示されます。

  6. 製品をクリックして選択し、[Continue] をクリックして、そのダウンロード可能パッケージを検索します。
    ヒント: (各製品のダウンロード文書に明記されている) ダウンロードパッケージの部品番号が分かっている場合は、その部品番号で検索すると、ダウンロード可能パッケージを素早く見つけることができます。

    ソフトウェア製品は、さまざまなオペレーティングシステムおよび言語と組み合わせて使用するために、異なるバージョンの製品を収録している投稿済みの「アセンブリ」です。パッケージ化は、各製品のサイズや複雑さによって異なります。

  7. [Select criteria] の下で、ダウンロードする製品の言語およびプラットフォーム (オペレーティングシステム) を選択します。
    製品の言語とプラットフォームを選択します。
  8. [Download options] の下で、オプション [If available, would you like to see associated products at no additional charge?] に対して [Yes] を選択します。

    こうすることにより、主要製品 (例えば、ユーザー名を保管できる LDAP ディレクトリサーバー) と併用するオプションの製品を表示およびダウンロードできるようになります。

    [Yes] を選択して、関連製品を無償で組み込む。
  9. [Continue] をクリックします。

    パスポートアドバンテージに、選択した基準に合致するアセンブリ (パッケージ) のリストが表示されます。

  10. ダウンロードの対象を以下から選択します。
    • 含まれるパッケージをすべてダウンロードするには、アセンブリを選択します。
      アセンブリを選択して、すべてのパッケージをダウンロードします。
    • [+] をクリックしてアセンブリを展開すると、個々のパッケージを選択できます。
      アセンブリを展開すると、ダウンロードする特定のパッケージを選択できます。
    重要: 製品の『クイックスタートガイド』のコピーは、常にダウンロードしてください。この資料には、製品のインストールに関する概要のほか、他の資料へのリンクも記載されています。
  11. ダウンロードする項目を選択し、ページの下部までスクロールします。
  12. ご使用条件の内容を確認して、[I agree] をクリックします。
  13. [Download] をクリックし、コンピュータ上の場所を選択して、ダウンロードしたファイルを保管します。
次のタスク

インストールの概要や製品資料へのリンクについて『クイックスタートガイド』を確認します。そこには、製品のインストール手順が記載されています。

インストール時に使用する node.cfg ファイルの準備

IBM Sametime Unified Telephony デプロイメントでテレフォニー制御サーバーをインストールするときに使用する、node.cfg ファイルを作成します。

始める前に

テレフォニー制御サーバーのインストールを準備するために、そのサーバーのハードウェアにアクセスする必要はありません。node.cfg ファイルは、無人インストールを実施するために必要なすべてのサイト固有情報が記載されている設定ファイルです。ファイルを作成するには、以下のリソースと情報が必要です。

  • NCPE (Node Configuration Parameters Editor) ウィザード。このウィザードでは、テレフォニー制御サーバーのインストールに使用される node.cfg ファイルをセットアップすることができます。このウィザードは .iso イメージファイルであり、Connect Server パッケージに含まれています。このウィザードのコピーを CD に書き込むことにより、Microsoft Windows または Linux が稼働しているコンピュータで実行することができます。
  • 2 つの USB フラッシュドライブ。2 つのテレフォニー制御サーバーノードをインストールするときに使用するために、それぞれに node.cfg のコピーを格納します。
  • 2 つのテレフォニー制御サーバーノードのインストールに必要な 17 の IP アドレス。
  • ゲートウェイ、DNS、NTP アドレス。
  • Sametime Unified Telephony デプロイメントで使用するサブネットの数 (シグナリングネットワーク、課金ネットワーク、管理ネットワークを別個に設定するかどうかなど)、それらのサブネットを別個の vLAN 上に配置するかどうか。
    注: 2 つのサブネットのみを実行することは可能です。ウィザードは警告を表示しますが、無視できます。
このタスクについて

参照イメージ DVD を使用してテレフォニー制御サーバーのインストールを実行します。この DVD には、デフォルトのシステム構成データ (オペレーティングシステムのパラメータ、Unix アカウント、node.cfg の IP パラメータ、RTP パラメータなど)、インストールスクリプトが含まれています。node.cfg ファイルの作成時に、デプロイメントの実際のパラメータを指定します。テレフォニー制御サーバーのインストール時には、node.cfg ファイル内の設定値が参照イメージに格納されているデフォルト値よりも優先します。2 つのテレフォニー制御サーバーノード上で同時にインストールを実行できるように、2 つの参照イメージ DVD のコピーが提供されます。

手順
  1. NCPE ウィザード .iso ファイルを CD にディスクイメージとして焼き付けます。
  2. 以下のようにディスクから NCPE ウィザードを開始します。
    • Linux
      ターミナル (xTerm など) を開き、CD ドライブに移動します。Linux のバージョンに応じて、/mnt/cdrom または /media/cdrom に格納されたファイルのアクセス権を確認します (つまり、ファイル cdrom/ncpe/bin/ncpe を確認します)。 このファイルが実行可能でない場合、NCPE ディレクトリ全体をローカルファイルシステム上にコピーする必要があります。このローカルファイルシステム上で、以下のコマンドを使用して、アクセス権を変更できます。
      #chmod 700 ncpe_location/ncpe/bin/ncpe
    • Windows

      Windows エクスプローラを開き、CD を参照します。RunIfGui.bat をダブルクリックして、実行します。

  3. [Installation Framework] 画面で、[Install] を選択し、[Next] をクリックしてウィザードを開始します。
    NCPE ウィザードの開始
次のタスク

以下の 2 つのトピックの説明に従って、ウィザードを実行します。 ウィザードが終了すると、テレフォニー制御サーバーのインストール時に使用する node.cfg ファイルの構成が完了します。

NCPE ウィザードを使用した node.cfg ファイルの生成

NCPE ウィザードを実行して、構成設定を指定します。この設定は、node.cfg ファイルに格納され、IBM Sametime Unified Telephony デプロイメントでインストール中に、各テレフォニー制御サーバーに適用されます。

始める前に

インストール時に使用する node.cfg ファイルの準備の説明に従って、NCPE ウィザードを開始します。

手順
  1. [Configuration and Hardware (1/1)] 画面で、少なくとも以下のフィールドに入力し、[Next] をクリックします。
    オプション 説明
    Hardware Platform 以下のいずれかを選択します。
    • IBM x3550M3 (標準デプロイメント)
    • Virtual-OSV (仮想化デプロイメント)
    [Configuration] [Standard Duplex] を選択します。
    Node Separation 以下のいずれかを選択します。
    • テレフォニー制御サーバーのノードに対して地理的な分離が使用されない場合、[not] です。
    • テレフォニー制御サーバーのノードが地理的に分離される場合、[separate] です。
    Survival Authority Survival Authority サービスが稼働されているコンピュータの IP アドレスを入力します。

    テレフォニー制御サーバーノードが地理的に分離されていない場合は、Survival Authority をテレフォニーアプリケーション制御サーバーの IP アドレスに設定できます。これは、Survival Authority として機能する CMP もそのコンピュータによってホストされているためです。システムが地理的に分離されている場合は、建物への接続に障害が発生する可能性があるため、Survival Authority を中央に配置したいことがあります。しかし、内部の機能はすべて稼働しており、その建物と外部との接続が切断されても、Survival Authority は引き続き Node1 と通信できる場合があります。その場合、Node2 は Node1 および Survival Authority と通信できなくなり、それが問題であるかのように動作します。Node1 は Node2 と通信できなくなりますが、Survival Authority との対話は引き続き可能であるため、これまでどおり作動します。実際にはこれと反対の状況が発生しており、Node2 による引き継ぎが必要です。

    最良の結果を得るためには、以下を実行します。
    1. テレフォニー制御サーバークラスタ内のすべてのノードが地理的に同じ場所にある場合は、テレフォニー制御サーバー/CMP Survival Authority を使用します。
    2. テレフォニー制御サーバーノードが地理的に分離されている場合は、スタンドアロン Survival Authority を使用します (第 3 のロケーションに配置することが望まれます)。
    [Configuration and Hardware] 画面
  2. [Cluster Installation (1/1)] 画面で、クラスタおよび各ノードの記述名を入力し、[Next] をクリックします。

    この情報は、コール処理ソフトウェアによって使用されます。外部通信で使用される場合もあります。クラスタ名およびノード名は、ClusterName-Node1Name-Node2Name のように結合されてデフォルト名が作成され、テレフォニー制御サーバーアシスタントを使用してクラスタに接続したときに、この名前が表示されます。

    例えば、以下の名前を指定するとします。
    • [Cluster Name]: tcscluster
    • [Node 1 Name]: tcsnode1
    • [Node 2 Name]: tcsnode2
    クラスタ名は、tcscluster-tcsnode1-tcsnode2 と表示されます。
    [Cluster Installation] 画面
  3. [IP Configuration (1/3)] 画面で、以下の管理、シグナリング、課金の各サブネットの IP アドレスを入力します。

    デフォルトでは、テレフォニー制御サーバーは、3 つの分離されたサブネットを構成します。分離されたサブネットを使用しない場合、各ネットワークのネットマスクを同一にし、少なくとも 64 ビットにする必要があります (255.255.255.192 など)。

    [IP Configuration (1/3)] 画面
  4. [IP Configuration (2/3)] 画面で、以下の情報を入力し、[Next] をクリックします。
    • [DNS Configuration] セクション: 最大 3 台の DNS サーバーの IP アドレスを [Name Server IP x] フィールドに入力します。
    • [NTP Configuration] セクション: 最大 2 台の NTP サーバーの完全修飾ドメイン名を [Server x] フィールドに入力します。
    [IP Configuration (2/3)] 画面
  5. [IP Configuration (3/3)] 画面で、以下の情報を入力します ([Next] はクリックしないでください)。
    オプション 説明
    Default Router Node 1 ノード 1 のデフォルトルーターの IP アドレスを入力します。
    Domain Name ノード 1 のデフォルトルーターの完全修飾ドメイン名を入力します。
    Cluster Name このフィールドには、ステップ 2 で指定したクラスタ名とノード名を結合して作成された、デフォルトのクラスタ名が表示されます。ここで新しい名前を入力して、この名前を上書きできます。
    [IP Configuration (3/3)] 画面
  6. [Expert] ボタンをクリックします ([Next] ではありません)。

    エキスパートモードを使用して、テレフォニー制御サーバーに接続するすべての CSTA サーバー (すべてのテレフォニーアプリケーションサーバーノード) の IP アドレスを指定することで、CSTA 接続を構成します。

  7. [Expert Mode] 画面で、ナビゲーションツリーの [IP Configuration (4/6)] をクリックします。
  8. [IP Configuration (4/6)] 画面の [CSTA Servers] セクションで、以下を行います。
    1. [CSTA Server] フィールドに、1 つのテレフォニーアプリケーションサーバーノードの IP アドレスを入力します。
    2. 別の CSTA を追加するボタン ボタンをクリックして、別の CSTA サーバーを追加します。
    3. すべての CSTA サーバーを追加するまで繰り返します。

    フェイルオーバーシステムの場合、テレフォニーアプリケーションサーバー 1 次ノードとすべてのフェイルオーバーノードの物理 IP アドレスを使用します (仮想 IP アドレスを指定する必要はありません)。

    [Expert Mode: IP Configuration (4/6)] 画面
  9. 画面上部にある ウィザードに戻るボタン ボタンをクリックして、ウィザードに戻ります。
  10. ウィザードに戻ったら、現在の画面が [IP Security (1/3)] 画面であることを確認します。
  11. [IP Security (1/3)] 画面で、各テレフォニーアプリケーションサーバーの IP アドレスを "[SNMP Servers]" セクションの [Address] フィールドに入力し、[Next] をクリックします。

    これによって、テレフォニーアプリケーションサーバーは、テレフォニー制御サーバーからアラームを受信できるようになります。

  12. [IP Security (2/3)] セクションは空のままにして (課金ネットワークの情報を入力する必要はありません)、[次へ] をクリックします。
    [IP Security (2/3)] 画面
  13. [IP Security (3/3)] 画面で、設定をそのままにして、[Finish] ボタンをクリックします。
    IP Security (3/3) 画面
タスクの結果

ウィザードで構成した設定は、node.cfg ファイルに書き込まれ、テレフォニー制御サーバーがインストールされるときにデフォルト設定を上書きするために使用されます。

仮想ディスクでの node.cfg の保管

VMware を使用してデプロイする場合、USB メモリスティックの代わりに仮想ディスクを使用して、テレフォニー制御サーバー上に node.cfg ファイルをインストールします。

このタスクについて

仮想マシンと同じネットワークでアクセス可能な別個のコンピュータ上に仮想ディスクを作成し、node.cfg ファイルをその仮想ディスクにコピーしてから、仮想ディスクをインストール用にデータストアに転送します。

以下のオペレーティングシステムで仮想ディスクを作成することができます。

  • Microsoft Windows:

    winImage などの任意のイメージ処理ソフトウェアパッケージを使用して、仮想ディスクを作成してください。その際、必ず VMware ESXi 4.0 と互換性のあるパッケージを選択してください。

  • Linux:

    以下の手順に従い、Linux で仮想ディスクを作成します。

手順
  1. 次の手順に従って、仮想ディスクを作成します。
    1. root として (Linux) コンピュータにログインします。
    2. 以下のコマンドを実行します。
      dd if=/dev/zero of=/tmp/Node1.flp bs=1024 count=1024
      mkfs.msdos /tmp/Node1.flp
      cp /tmp/Node1.flp /tmp/Node2.flp

      以下の例は、仮想ディスクを作成するコマンドを実行したときに、画面がどのように表示されるかを示しています。

      root@fsc501:[/tmp] #216
      # dd if=/dev/zero of=/tmp/Node1.flp bs=1024 count=1024
      1024+0 records in
      1024+0 records out
      1048576 bytes (1.0 MB) copied, 0.004398 seconds, 238 MB/s
      root@fsc501:[/tmp] #217
      
      # mkfs.msdos /tmp/Node1.flp
      mkfs.msdos 2.11 (12 Mar 2005)
      root@fsc501:[/tmp] #218
      
      # cp /tmp/Node1.flp /tmp/Node2.flp
      root@fsc501:[/tmp] #219
      
      # ll /tmp/Node*
      -rw-r--r-- 1 root root 1048576 Feb 17 17:35 /tmp/Node1.flp
      -rw-r--r-- 1 root root 1048576 Feb 17 17:35 /tmp/Node2.flp

      この操作により、/tmp ディレクトリ内に Node1.flp および Node2.flp という 2 つの仮想ディスクデバイスが作成されます。

  2. 以下の手順により、node.cfg ファイルを仮想ディスクに保存します。
    1. root として (Linux) コンピュータにログインします。
    2. node.cfg ファイルを /tmp ディレクトリにコピーします。
    3. 以下のコマンドを実行して、このファイルを Node1 仮想ディスクにコピーします。
      mount -o loop /tmp/Node1.flp /media/floppy
      cp /tmp/node.cfg /media/floppy/node.cfg.primary
      umount /media/floppy
    4. 上記のコマンドに類似した以下のコマンドセットを実行して、ファイルを Node2 仮想ディスクにコピーします。
      mount -o loop /tmp/Node2.flp /media/floppy
      cp /tmp/node.cfg /media/floppy/node.cfg.secondary
      umount /media/floppy
  3. 次の手順で、VMware vSphere クライアントにログインします。
    1. IP アドレス/名前を入力します (ホストマシンにサービスを提供する仮想サーバーまたは VCenter サーバーの管理 IP)。
    2. ユーザー名を入力します (root または VCenter ログイン用のユーザー名)。
    3. VMware パスワードが作成されている場合は、ここでそのパスワードを入力します (パスワードの作成はオプションであるため、このステップは環境によって異なります)。
    4. [ログイン] を選択します。
  4. 仮想ディスクファイルの Node1.flpNode2.flp をデータストアに転送します。
    • 物理サーバーが 1 台だけの場合: 以下の手順を実行して、Node1.flpNode2.flp の両方をアップロードします。
      1. 仮想マシンの [要約] タブを選択します。
      2. データベースの名前を右クリックして、[データベースの参照] をクリックします。
      3. ルートディレクトリを選択し、[フォルダの追加] アイコンをクリックして、データストアのルートの下に論理フォルダを作成します。
      4. [新規フォルダ] フィールドに images などのフォルダ名を入力して [OK] をクリックします。
      5. 上記の新規ディレクトリを選択して [ファイルのアップロード] アイコンをクリックします。
      6. [ファイルのアップロード] を選択します。
      7. リストから Node1.flp を選択し、[開く] をクリックしてアップロードします。
      8. リストから Node2.flp を選択し、[開く] をクリックしてアップロードします。
    • 物理サーバーが 2 台ある場合: 以下の手順に従い、該当するファイルを各サーバーにアップロードします。
      1. Node1 仮想マシンの [要約] タブを選択します。
      2. Node1 のデータベースの名前を右クリックして、[データベースの参照] をクリックします。
      3. ルートディレクトリを選択し、[フォルダの追加] アイコンをクリックして、データストアのルートの下に論理フォルダを作成します。
      4. [新規フォルダ] フィールドに images などのフォルダ名を入力して [OK] をクリックします。
      5. 上記の新規ディレクトリを選択して [ファイルのアップロード] アイコンをクリックします。
      6. [ファイルのアップロード] を選択します。
      7. リストから Node1.flp を選択し、[開く] をクリックしてアップロードします。
      8. Node2 仮想マシンの [要約] タブを選択します。
      9. Node2 のデータベースの名前を右クリックして、[データベースの参照] をクリックします。
      10. ルートディレクトリを選択し、[フォルダの追加] アイコンをクリックして、データストアのルートの下に論理フォルダを作成します。
      11. [新規フォルダ] フィールドに images などのフォルダ名を入力して [OK] をクリックします。
      12. 上記の新規ディレクトリを選択して [ファイルのアップロード] アイコンをクリックします。
      13. [ファイルのアップロード] を選択します。
      14. リストから Node2.flp を選択し、[開く] をクリックしてアップロードします。
実際のインストールの実施

以下の手順に従って、IBM Sametime Unified Telephony デプロイメントの準備済みサーバーにテレフォニー制御サーバーアプリケーションをインストールします。

始める前に
以下のものが必要です。
  • テレフォニー制御サーバーのインストーラが格納されている 2 枚の DVD が準備されていること
  • 2 本の USB メモリスティック (標準デプロイメントの場合)
  • NCPE ツールで作成および検証された準備済み node.cfg ファイル
手順
  1. テレフォニー制御サーバーコンピュータを確認します。
    1. テレフォニー制御サーバーが電源遮断の状態にあり、新規構成のために使用可能であることを確認します。
    2. ケーブル接続と必要なハードウェア構成を確認します。
      注: クラスタ相互接続が適切でない場合、インストールプロセスは停止します。
    3. インストールプロセスをモニターするためのコンソールが両方のノードで使用可能であることを確認します。
  2. 以下の手順で、node.cfg ファイルをインストールに使用できるように準備します。
    • 標準デプロイメント: 2 つの空の FAT32 形式 USB ドライブのそれぞれに上記のファイルをコピーします。USB 1 では node.cfg.primary、USB 2 では node.cfg.secondary という名前にします。
    • 仮想化デプロイメント: 仮想ディスクでの node.cfg の保管で説明しているように、ファイルが仮想フロッピーにコピーされ、データストアにアップロードされたことを確認します。
  3. テレフォニー制御サーバーのソフトウェアインストール DVD を挿入し、システムの電源をオンにして、インストール手順を実行します。
  4. プロンプトが表示されたら、適切な USB ドライブを挿入します。

    インストールには約 30 分かかります。インストール中にシステムが数回リブートされます。インストールが完了すると、以下のメッセージが表示されます。– system was started on node1 node! この例では、node1 がノードの名前です。

ライセンスを取得してテレフォニー制御サーバークラスタに適用する

テレフォニー制御サーバーが IBM Sametime Unified Telephony デプロイメント内で正常に動作するためには、必要なライセンスを取得してインストールする必要があります。テレフォニー制御サーバーライセンスは、eth0 ネットワークインターフェースカードの MAC アドレスに固定されます。必要なライセンスを取得するには、インストール担当者または管理者が各ノードの eth0 インターフェースの MAC アドレスを取り出す必要があります。ライセンスはノードに結び付けられます。

このタスクについて
できるだけ早くライセンスを請求してください。ライセンスを受け取るまで少なくとも 2 日はかかります。
手順
  1. 両方のノードに「root」ユーザーとしてログインし、各ノードでコマンド tcsnode:# ifconfig eth0 | grep HWaddr を実行します。
  2. テレフォニー制御サーバーノードの両方に MAC アドレスがある場合は、両方のノードのライセンスファイルを Sametime Unified Telephony の連絡先から請求してください。受け取るファイルは 2 つ (ノードごとに 1 つずつ) です。これらのライセンスファイルのファイル名には MAC アドレスが含まれていて、どのファイルがどのノードに属するかが分かるようになっています。
  3. 2 つのライセンスファイルを受け取ったら、次にそれらを各テレフォニー制御サーバーノードに適用する必要があります。
    1. 各テレフォニー制御サーバーノードに対して scp (winSCP) セッションを開きます。
    2. ディレクトリを /opt/unisphere/srx3000/cla/import に変更します。
    3. 一致する MAC アドレスがファイル名に含まれているライセンスファイルを、その MAC アドレスを持つ TCS ノードにコピーします。
    ファイルがディレクトリにコピーされると、ファイルはそのノードのライセンスエージェントによって適用され、その後、ディレクトリから削除されます。ライセンスエージェントは 5 秒ごとにディレクトリを検査するため、ライセンスファイルは 5 秒以内に適用され、ディレクトリから削除されます。
  4. ライセンスが適用されたことを確認します。
    1. CMP を開きます。
    2. [Telephony Control Server] > [Administration] > [Licensing Management] > [License Usage] をクリックします。
    3. [License Usage] ウィンドウで、[Licensed] の数と [Used] の数が一致していることを両方のノードで確認し、[Close] をクリックしてウィンドウを閉じます。
次のタスク

両方のテレフォニー制御サーバーノードをインストールしたら、「テレフォニーアプリケーションサーバーのインストール」に進みます。

テレフォニーアプリケーションサーバーのインストール

IBM Sametime Unified Telephony と共に使用するテレフォニーアプリケーションサーバーのインストールでは、いくつかのサポート製品をインストールする必要があります。このセクションで説明されているように必要な製品をすべてインストールしてください。

このタスクについて

テレフォニーアプリケーションサーバーをインストールするには、その前に SUSE Linux Enterprise Server をインストールしておく必要があります。

次に、テレフォニーアプリケーションサーバーソフトウェアをインストールするときには、テレフォニーアプリケーションサーバーソフトウェアにバンドルされている以下のアプリケーションも、サーバー上にインストールされます。
  • IBM Tivoli® System Automation for Multiplatforms
  • Telephony Application Server Framework
  • IBM WebSphere® Application Server
  • IBM Tivoli Directory Integrator
  • アセンブリ行スクリプト
  • 管理アプリケーション
  • OSGi バンドル
  • コール履歴データベース表
注: Sametime Media Manger デプロイメントに含まれている SIP Proxy and Registrar サーバーをインストールする必要があります。SIP Proxy and Registrar のインストール手順については、Sametime Wiki 内のセクション「Installing Sametime Media Manager」を参照してください。
テレフォニーアプリケーションサーバーのインストール時レイアウト
テレフォニーアプリケーションサーバーのインストールパッケージのダウンロード

テレフォニーアプリケーションサーバー用の IBM Sametime Unified Telephony インストールパッケージをダウンロードして解凍します。

このタスクについて

テレフォニーアプリケーションサーバーは、Linux オペレーティングシステムと一緒にパッケージ化されています。この複合パッケージは、ダウンロード文書では「コールサーバー」と呼ばれています。

手順
  1. 次のいずれかを実行します。
  2. 次のコマンドを実行して、/software/IBM というディレクトリを作成します。
    mkdir /software/IBM
  3. 新しい /software/IBM ディレクトリにパッケージをコピーします。
    DVD の場合、以下のコマンドを使用します。
    cp /DVD_mount_point/file_name.tgz /software/IBM
  4. その新規ディレクトリにナビゲートします。
    cd /software/IBM
  5. 最後に、次のコマンドを使用して、適切なインストーラを解凍します。
    tar xvfz file_name.tgz
パスポートアドバンテージを使用した、テレフォニーアプリケーションサーバーパッケージのダウンロード

IBM パスポートアドバンテージ Web サイトには、入手資格のあるすべてのソフトウェアへのアクセスが用意されています。インストールするために製品をコンピュータに直接ダウンロードでき、IBM Sametime のインストールを開始する方法を参照するために『クイックスタートガイド』をダウンロードできます。

このタスクについて

パスポートアドバンテージでは、IBMソフトウェア購入製品へのアクセスを提供しているため、インストール先にするコンピュータに製品を直接ダウンロードできます。パスポートアドバンテージプログラムの詳細については、プログラムの概要を参照してください。

パスポートアドバンテージから製品をダウンロードするには、IBM カスタマー ID が必要です。カスタマー ID をお持ちでない場合は、以下のようにしてパスポートアドバンテージのサイトに登録する必要があります。
  1. ブラウザを開き、パスポートアドバンテージのサインインページにナビゲートします。
  2. 新規のお客様登録フォームに入力します。
  3. [Register] をクリックします。
IBM カスタマー ID を受け取ったら、以下の手順での説明に従って製品のダウンロードに進みます。
手順
  1. ブラウザを開き、パスポートアドバンテージのサインインページにナビゲートします。
  2. [Customer sign in] をクリックします。
  3. お客様の IBM カスタマー ID とパスワードを入力して、[Sign in] をクリックします。
  4. [Software and services online] ページで、[Software download & media access] をクリックします。
    [Software download & media access] リンクをクリックします。
  5. [Find downloads & media] ページで、[Download finder] をクリックします。
    [Download finder] リンクをクリックします。

    パスポートアドバンテージには、ダウンロードの権利がある (購入した) 製品のリストが表示されます。

  6. 製品をクリックして選択し、[Continue] をクリックして、そのダウンロード可能パッケージを検索します。
    ヒント: (各製品のダウンロード文書に明記されている) ダウンロードパッケージの部品番号が分かっている場合は、その部品番号で検索すると、ダウンロード可能パッケージを素早く見つけることができます。

    ソフトウェア製品は、さまざまなオペレーティングシステムおよび言語と組み合わせて使用するために、異なるバージョンの製品を収録している投稿済みの「アセンブリ」です。パッケージ化は、各製品のサイズや複雑さによって異なります。

  7. [Select criteria] の下で、ダウンロードする製品の言語およびプラットフォーム (オペレーティングシステム) を選択します。
    製品の言語とプラットフォームを選択します。
  8. [Download options] の下で、オプション [If available, would you like to see associated products at no additional charge?] に対して [Yes] を選択します。

    こうすることにより、主要製品 (例えば、ユーザー名を保管できる LDAP ディレクトリサーバー) と併用するオプションの製品を表示およびダウンロードできるようになります。

    [Yes] を選択して、関連製品を無償で組み込む。
  9. [Continue] をクリックします。

    パスポートアドバンテージに、選択した基準に合致するアセンブリ (パッケージ) のリストが表示されます。

  10. ダウンロードの対象を以下から選択します。
    • 含まれるパッケージをすべてダウンロードするには、アセンブリを選択します。
      アセンブリを選択して、すべてのパッケージをダウンロードします。
    • [+] をクリックしてアセンブリを展開すると、個々のパッケージを選択できます。
      アセンブリを展開すると、ダウンロードする特定のパッケージを選択できます。
    重要: 製品の『クイックスタートガイド』のコピーは、常にダウンロードしてください。この資料には、製品のインストールに関する概要のほか、他の資料へのリンクも記載されています。
  11. ダウンロードする項目を選択し、ページの下部までスクロールします。
  12. ご使用条件の内容を確認して、[I agree] をクリックします。
  13. [Download] をクリックし、コンピュータ上の場所を選択して、ダウンロードしたファイルを保管します。
次のタスク

インストールの概要や製品資料へのリンクについて『クイックスタートガイド』を確認します。そこには、製品のインストール手順が記載されています。

SUSE Linux と Tivoli System Automation for Multiplatforms のインストール

SUSE Linux と IBM Tivoli System Automation for Multiplatforms を、テレフォニーアプリケーションサーバーまたはオフボード Media Server をホストするコンピュータ上にインストールします。

始める前に

以下の項目がインストール用に準備されていることを確認してください。

  • 最小ハードウェア所要量
  • SUSE Linux Enterprise Server 11 SP2 64 ビットのすべての CD、テレフォニーアプリケーションサーバーのインストーラ DVD

必要なバージョンの Linux SUSE がサーバー上に既にインストールされている場合は、次のタスクに進む前に、以下の要件が満たされていることを確認するだけでかまいません。

  • グラフィカルデスクトップが GNOME または KDE のいずれかであること
  • ブート時のデフォルトのランレベルが 3 (ネットワーク有のマルチユーザーモード) であること
  • ネットワーク設定で、[DHCP でホスト名を変更する] オプションが使用不可であること
このタスクについて

このタスクには、SUSE Linux と System Automation for Multiplatforms の両方をインストールするステップが含まれます。

このトピックのスクリーンショットは SLES 10 を表示していますが、これらは SLES 11 SP2 64 ビットインストールに表示されるものとほぼ同じです。

注: SLES 10 ではデフォルトのファイルシステムタイプは reiserfs ですが、SLES 11 ではバックアップとリカバリーでの既知の制限を避けるためにデフォルトとして ext3 を使用する必要があります。
手順
  1. CD1 SUSE Linux Enterprise Server からマシンをブートします。[インストール] を選択します。
    マシンをブートするために [インストール] を選択する画面のキャプチャ。
  2. [インストールモード (Installation Mode)] 画面で、[新規インストール (New Installation)] を選択します。[次へ] をクリックします。
    インストールモードの画面
  3. [インストール設定] 画面で、[ソフトウェア] をクリックします。
    インストール設定の画面
  4. [ソフトウェア選択およびシステムタスク (Software Selections and Systems Task)] 画面で以下の変更を行って [了承] をクリックします。
    • [Novell AppArmor] を使用不可に設定 (選択解除) します。
    • [Gnome] を使用不可に設定 (選択解除) します。
    • [Print Server] を使用不可に設定 (選択解除) します。
    • [KDE] を使用可能に設定 (選択) します。
    ソフトウェア選択とシステムタスクの画面
  5. [ホスト名およびドメイン名 (Host name and Domain Name)] 画面で、[DHCP を介してホスト名を変更 (Change host name through DHCP)] オプションを使用不可に設定します。[次へ] をクリックします。
    ホスト名とドメイン名の画面
  6. [ネットワーク構成] 画面で [ファイアウォール] リンクをクリックします。
    ネットワーク構成の画面
  7. [サービス開始ウィンドウ (Service Start Window)][ファイアウォール構成: 開始 (Firewall Configuration: Start-Up)] 画面で、[手動 (Manually)] を選択します。[同意する] をクリックします。
    ファイアウォール構成:
開始の画面
  8. [ネットワーク構成] 画面で [IPV6]リンクをクリックします。
    ネットワーク構成の画面
  9. [ネットワークセットアップ方法 (Network Setup Method)] 画面で、[IPv6 の無効化 (Disable IPv6)] を選択します。[次へ] をクリックします。
    ネットワークセットアップ方法の画面
  10. [ネットワーク構成] 画面で [ネットワーク・インターフェース] リンクをクリックします。
    ネットワーク構成の画面
  11. [ネットワークカード構成の概要 (Network Card Configuration Overview)] 画面で、[編集] をクリックします。
    ネットワークカード構成の概要画面
  12. [ネットワークアドレスのセットアップ (Network Address Setup)] 画面で、[静的アドレスのセットアップ (Static Address Setup)] を選択し、IP アドレスとサブネットマスクを入力し、ホスト名をクリックして、サーバーの名前を指定します。
    ネットワークアドレス設定の画面
  13. [ホスト名およびネームサーバー構成 (Host Name and Name Server Configuration)] 画面で、[ホスト名][ドメイン名][ネーム・サーバー 1 (Name Server 1)] を入力し、[OK] をクリックします。
    ホスト名とネームサーバー構成の画面
  14. [ネットワークアドレスのセットアップ (Network Address Setup)] 画面で、[ルーティング (Routing)] をクリックします。
    ネットワークアドレス設定の画面
  15. [ルーティング構成 (Routing Configuration)] 画面で、[デフォルトゲートウェイ (Default Gateway)] を入力し、[OK] をクリックします。
    ルーティング構成の画面
  16. [ネットワークアドレスのセットアップ (Network Address Setup)] 画面で、[次へ] をクリックします。
    ネットワークアドレス設定の画面
  17. まだ [ネットワークインターフェース] がある場合は、[ネットワークカード構成の概要 (Network Card Configuration Overview)] 画面で、それらを構成し、[次へ] をクリックします。
    ネットワークカード構成の概要画面
  18. [ネットワーク構成] 画面で [VNC リモート管理] リンクをクリックします。
    ネットワーク構成の画面
  19. [リモート管理 (Remote Administration)] 画面で、[リモート管理を許可 (Allow Remote Administration)] を選択し、[終了] をクリックします。
    リモート管理の画面
次のタスク

SUSE Linux をインストールしたら、YaST を使用して、「novell-zmd」サービスおよび「suseRegister」サービスを手動で非アクティブ化します。

Installation Manager のインストール

IBM Installation Manager をインストールして、次のタスクの IBM WebSphere Network Deployment をインストールできるようにします。

始める前に
  • GUI モードを使用してインストールする場合、完全な X11 デスクトップ環境が必要です。
  • Linux: ランチパッドのインストールプログラムによって Web ブラウザが起動されます。コンソールを使用しているか、X サーバーと Web ブラウザがインストールおよび構成されている必要があります (VNC またはリモート xterm セッションも機能します)。Linux の場合、Installation Manager が正しく機能するためには、グラフィカルライブラリページもインストールする必要があります。インストール時に作成されるユーザー用のホームディレクトリがシステム上に作成されるようにするためには、/home ディレクトリが書き込み可能である必要があります。
このタスクについて

Installation Manager のインストールの詳細については、Installation Manager インフォメーションセンターの「ウィザード・モードの使用による Installation Manager のインストール」を参照してください。

手順
  1. Installation Manager をインストールするコンピュータに root としてログオンします。
  2. Installation Manager パッケージを解凍したディレクトリーに移動します。
  3. コマンド ./install.sh を実行して、インストールを開始します。
  4. 以下の手順で、Installation Manager をインストールします。
    1. [パッケージのインストール] ページで、[Installation Manager] > [バージョン 1.6.2] が選択されていることを確認し、[次へ] をクリックします。
    2. [ライセンス] ページで、[使用条件の条項に同意します] をクリックしてから、[次へ] をクリックします。
    3. [ロケーション] ページで、デフォルトの場所をそのまま使用するか、新しいロケーションを選択して、[次へ] をクリックします。
    4. [要約] ページで、選択内容を検討してから [インストール] をクリックします。

      リポジトリは、デフォルトで現在のディレクトリ (Installation Manager を解凍した場所) に設定されるため、変更する必要はありません。

    5. インストールが完了したら、[Installation Manager の再起動] をクリックします。
WebSphere Network Deployment のインストール

IBM Installation Manager を使用して、IBM WebSphere Network Deployment 64 ビットサーバーをフルプロファイルと共にインストールしてから、アプリケーションサーバー構成プロファイルを作成します。

始める前に

複数のパーツ、フィックスパック、ifix を含むすべての WebSphere パッケージをダウンロードして解凍します。

このタスクについて

WebSphere Network Deployment のインストールの詳細については、WebSphere インフォメーションセンター内の「GUI を使用した、分散オペレーティング・システムでの製品のインストール」を参照してください

手順
  1. WebSphere Network Deployment をインストールするコンピュータ上で、root としてログオンします。
  2. Installation Manager がまだ実行されていない場合は、以下の手順で開始します。
    1. コマンドウィンドウを開き、Installation Manager がインストールされている場所に移動します。デフォルトの場所は /opt/IBM/InstallationManager/eclipse です。
    2. 以下のコマンドを実行して、Installation Manager をインストールします。 ./launchpad.sh
  3. WebSphere Network Deployment パッケージを解凍した各ディレクトリの repository.config ファイルを指すように、リポジトリのロケーションを設定します。

    基本製品だけでなく、すべてのフィックスパックと ifix のリポジトリも選択してください。

    1. [Installation Manager] ウィンドウで、[ファイル] > [設定]をクリックします。
    2. [設定] ページで、[リポジトリー] をクリックします。
    3. 以下のように、基本 WebSphere Network Deployment パッケージ用のリポジトリを追加します。
      1. [リポジトリー] ページで、[リポジトリーの追加] をクリックします。
      2. [リポジトリーの追加] ページで、[参照] をクリックします。
      3. [リポジトリーの選択] ページで、WebSphere Network Deployment 8.5.5.0 の解凍済みファイルが格納されているロケーションを参照し、最上位ディレクトリで repository.config ファイルを探します。
      4. repository.config ファイルをクリックして選択してから、[適用] をクリックします。
    4. 以下のように、WebSphere Network Deployment Fix 8.5.5.0 Pack のリポジトリを追加します。
      1. [リポジトリー] ページで、[リポジトリーの追加] をクリックします。
      2. [リポジトリーの追加] ページで、[参照] をクリックします。
      3. [リポジトリーの選択] ページで、WebSphere Network Deployment Fix Pack の解凍済みファイルを保管した場所を参照し、最上位ディレクトリ内の repository.config ファイルを見つけます。
      4. repository.config ファイルをクリックして選択してから、[適用] をクリックします。
    5. 以下のリスト内の各 iFix のリポジトリを追加します。
      1. [リポジトリー] ページで、[リポジトリーの追加] をクリックします。
      2. [リポジトリーの追加] ページで、[参照] をクリックします。
      3. [リポジトリーの選択] ページで、ifix の解凍済みファイルが格納されているロケーションを参照し、最上位ディレクトリで repository.config ファイルを探します。
      4. repository.config ファイルをクリックして選択してから、[適用] をクリックします。
      5. 残りの各 ifix に対してこの手順を繰り返します。
    6. [リポジトリー] ページに戻り、[インストール中および更新中にサービス・リポジトリーの検索] をクリックします。これにより、インストール済みパッケージに対する更新があるかどうかを Installation Manager で確認できるようになります。
    7. [OK] をクリックします。
  4. メインの [Installation Manager] ウィンドウに戻って [インストール] をクリックします。
  5. [IBM WebSphere Application Server Network Deployment 8.5.5.0] を選択して、[次へ] をクリックします。
  6. インストールする修正を選択して、[次へ] をクリックします。
  7. 使用条件の条項に同意し、[次へ] をクリックします。
  8. Windows の場合のみ、インストールディレクトリを修正し、[次へ] をクリックします。

    Installation Manager は、デフォルトで C:¥Program Files ディレクトリを選択しますが、このディレクトリ名にスペースが含まれていることが原因で、WebSphere で問題が発生します。最良の結果を得るには、このパスから「Program Files」を削除して「C:¥IBM」としてください。

  9. 言語として英語を受け入れて、[次へ] をクリックします。
  10. インストールするフィーチャセットを選択して、[次へ] をクリックします。
    1. IBM WebSphere Application Server Network Deployment 8.5.5.0 フィーチャセットを展開します。
    2. [WebSphere Application Server Full Profile] を選択して、フルプロファイルを選択します (Liberty プロファイルは Sametime Unified Telephony 9 ではサポートされません)。
    3. [IBM 32-bit WebSphere SDK for Java] の選択をクリアします。
    4. 代わりに [IBM 64-bit WebSphere SDK for Java] を選択します。
  11. 要約情報を確認して [インストール] をクリックします。
  12. インストールの最後に、[プロファイル管理ツールを使用してプロファイルを作成する (Use Profile Management Tool to create a profile)] をクリックしてから [終了] をクリックします。

    Profile Management Tool が即座に開きます。

  13. [プロファイル管理ツール] で、デフォルトオプションをそのまま使用して [アプリケーション・サーバー] プロファイルを作成し、[次へ] をクリックします。
  14. デフォルトの [標準] プロファイル設定を受け入れて、[次へ] をクリックします。
  15. ユーザー ID とパスワードを入力して WebSphere 管理者アカウントを作成し、[次へ] をクリックします。
  16. [作成] をクリックして新しいプロファイルを生成します。
  17. [ファースト・ステップの起動] オプションを選択解除して、[終了] をクリックします。
  18. プロファイル管理ツールを閉じます。
  19. Installation Manager を閉じます。
  20. アップグレードの場合のみ: WebSphere Network Deployment を、テレフォニーアプリケーションサーバーのアップグレードの一環としてインストールした場合は、以下のコマンドを実行します。
    touch /opt/IBM/WebSphere/AppServer/WAS1

    WAS1 は、アップグレードするノードのノード ID を表しています。

フェイルオーバーサービスのセットアップ

テレフォニーアプリケーションサーバーを IBM Sametime Unified Telephony デプロイメントにインストールする前に、 フェイルオーバーサービスをセットアップする必要があります。

このタスクについて

Sametime Unified Telephony は、IBM Tivoli System Automation for Multiplatforms (SAMP) を使用して、 テレフォニーアプリケーションサーバー用のフェイルオーバーサービスを実現します。 SAMP は、以下のフェイルオーバーサービスを提供します。

  • 高可用性環境。この環境では、システムを連続的に使用することが可能です。また、 その自己修復インフラストラクチャにより、システムの問題によって発生するダウン時間が防止されます。
  • システムリソース (プロセスやファイルシステムなど) の自動制御。
  • 復旧プロセスとワークフロープロセス。ソフトウェアまたはハードウェアの障害が発生したときに、 ユーザー、リソース、アプリケーションをクラスタサーバー間で自動的に切り替えます。

このセクションでは、SAMP フェイルオーバーサービスの使用法をより詳しく説明します。 また、SAMP 基本コンポーネントをテレフォニーアプリケーションサーバーにインストールする手順も説明します。

フェイルオーバーサービスの理解

System Automation for Multiplatforms (SAMP) は、IBM Sametime Unified Telephony デプロイメントで テレフォニーアプリケーションサーバー用のフェイルオーバーサービスを提供するために使用する Tivoli からのオファリングです。

SAMP の機能
  • 高可用性と自動化を実現します。IT の可用性に影響を与えるインシデントの頻度と継続時間を削減します。
  • IT リソース (プロセスやファイルシステムなど) の制御を自動化します。
  • ソフトウェアまたはハードウェアに障害が発生した後、ユーザー、リソース、アプリケーションを、 クラスタ内のあるシステムから別のシステムへと自動的に切り替えます。
  • 計画外の停止の 3 つの主要な原因に対処します。
    • ハードウェアの障害
    • ソフトウェアの障害
    • オペレータのエラー

SAMP は、高可用性環境を実現します。この環境では、システムを連続的に使用することが可能です。また、 その自己修復インフラストラクチャにより、システムの問題によって発生するダウン時間が防止されます。自己修復インフラストラクチャにより、システムの不正な操作、トランザクション、プロセスが検出され、ユーザーを混乱させることなく修正アクションが開始されます。

SAMP は、高可用性および自動化サービスを提供することにより、IT の可用性に影響を与えるインシデントの頻度と継続時間を削減します。 こうした高可用性を保証できるようにするために、SAMP は、高速障害検出、各アプリケーションコンポーネントとそれらの関係についての高度なナレッジを使用します。 これにより、障害が発生したリソースとビジネスアプリケーション全体を、同一ノード上または別のスタンバイシステム上で、迅速かつ矛盾のない方法で復旧します。

SAMP は、IT リソース (プロセスやファイルシステムなど) の制御を自動化します。 また、復旧プロセスまたはワークフローを自動化することによって障害を防止します。 SAMP は、ソフトウェアまたはハードウェアに障害が発生した場合、ユーザー、リソース、アプリケーションを、 クラスタ内のあるシステムから別のシステムへと自動的に切り替えます。

SAMP は、このサービスを提供するために、責任を持つリソース間の関係をクラスタ全体で管理します。 アプリケーションをノード間で移動させる必要がある場合は、開始と停止の関係、ノードの要件、任意の事前アクションまたは事後アクションが SAMP によって自動的に処理されます。 これにより、オペレータは、手動でコマンドを入力する必要がなくなり、オペレータのエラーのリスクが低減されます。

最後に SAMP は、計画外の停止の 3 つの主要な原因 (ハードウェアの障害、ソフトウェアの障害、オペレータのエラー) に対処します。

SAMP のアーキテクチャ

SAMP は、ポリシーベースの自動化ファイルを通じてリソースをモニターする基本コンポーネントから構成されます。 また SAMP は、異機種混合の高可用性ソリューションを一元的に管理する操作コンソールを備えています。

SAMP のアーキテクチャ

基本コンポーネント

SAMP 基本コンポーネントは、フェイルオーバークラスタの各ノード (スタンバイノードを含む) に配置されます。 各基本コンポーネントには、自動化アダプタが含まれます。 SAMP の基本コンポーネントの自動化アダプタは、自動化ドメインと SA 操作コンソール間の通信を確立して管理するために必要です。 AIX システムと Linux システムの場合、アダプタは、基本コンポーネントと共に自動的にインストールされます。

操作コンソール (オプション)
操作コンソールでは、異機種混合の高可用性ソリューションを一元的に管理することが可能です。 Tivoli System Automation for Multiplatforms 操作コンソールは、IBM Integrated Solutions Console で動作する Web ベースのユーザーインターフェースです。 Integrated Solutions Console は、管理コンソール機能の共通のフレームワークであり、WebSphere Portal Server 上に構築されます。 操作コンソールにアクセスする場合、クライアント上で必要なものは、Web ブラウザのみです。 SA 操作コンソールは、System Automation オペレータが毎日の操作タスクを実行するためのメインコンソールです。 例えば、操作コンソールを使用してアプリケーションを開始または停止するときは、 アプリケーションの依存関係を理解する必要はありません。また、アプリケーション固有の知識やオペレーティングシステム固有の知識も不要です。 他の一般的なオペレータタスクには、 アプリケーションの操作状況のモニター、自動化アプリケーションを使用した問題の診断、 アプリケーションの構成の選択の切り替え、 保守のためにノードを自動化から除外することなどがあります。
注: 操作コンソールをインストールするための要件はありませんが、操作コンソールのセットアップと構成の方法に関する説明が用意されています。 ただし、すべての保守タスクは、クラスタの任意のシステム (例えば、基本コンポーネントがインストールされた任意のシステム) 上で、コマンドライン呼び出しを使用して実行できます。

この製品に関する理解を深めるために、Tivoli SAMP Web サイトが用意されています。

フェイルオーバーと SAMP

IBM Tivoli System Automation for Multiplatforms (SAMP) を使用した IBM Sametime Unified Telephony のフェイルオーバー。

テレフォニーアプリケーションサーバーは、ウォームスタンバイモデルを使用したフェイルオーバーをサポートします。 ウォームスタンバイは、1 次システムのバックグラウンドでスタンバイシステムが稼働する冗長方式です。

Sametime Unified Telephony の高可用性クラスタを実現するためには、クラスタあたり 1 つのスタンバイノードが、サポートされる最小のデプロイメントです。必要に応じて、複数のスタンバイノードを設置することが可能です。 オフボード デプロイメントでは、1 つのスタンバイサーバーをすべてのテレフォニーアプリケーションサーバー用に使用し、別個のスタンバイサーバーを Media Server 用に使用できます。

フェイルオーバーモデルを用意すると、テレフォニーアプリケーションサーバーに障害が発生した場合、関連するテレフォニー制御サーバーが、デフォルト設定に基づいて、影響を受けるユーザーの呼び出しを経路指定できます。また、ウォームスタンバイノードは、障害が発生したテレフォニーアプリケーションサーバーにプロビジョニングされたユーザーのうち、影響を受けるユーザーについて引き継ぎを行います。その結果、Sametime Unified Telephony サービスの損失は、時間ではなく分単位で測定されます。

SAMP と Sametime Unified Telephony の操作上の注意

このセクションでは、System Automation for Multiplatforms と IBM Sametime Unified Telephony の操作上の注意点について説明します。

System Automation for Multiplatforms (SAMP) は、Sametime Unified Telephony プロセスやマウントされた Sametime Unified Telephony ディレクトリ、ネットワークインターフェース、仮想 IP アドレスなどのリソースを監視および管理します。SAMP では、高可用性クラスタ向けの IBM ソリューションである HACMP などのテクノロジが使用されています。

アクションは、XML ポリシー、より具体的には自動化ポリシーを通じて実装されます。したがって、SAMP では、各種のコンポーネント間の関係が定義された自動化ポリシーを使用して、高可用性システムを構成できます。 これらのポリシーは、軽微な変更を加えることで、既存のアプリケーションに適用できます。関係が設定されると、SAMP は、構成された特定のノード上のアプリケーションを管理する責任を引き受けます。 これにより、実装時間が削減され、アプリケーションの複雑なコーディングの必要性も減少します。

ポリシーは、ポーリングに基づいています。そのため、モニターに必要なすべてのリソースは、SAMP リソースとして定義する必要があります。SAMP リソースを定義する一環として、リソースを停止、開始するコマンド、リソースの状況を検査するコマンドを定義する必要があります。 SAMP は、モニターコマンドを使用して、事前設定された間隔でリソースをポーリングします。リソースが停止していた場合は、再起動を試みます。 この試みが失敗した場合、リソースは、スタンバイノードに切り替わり、このノード上で開始されます。

これらのポリシーには、「移動」のノードと「再起動」のノードで異なるパラメータを持つルールが含まれています。 移動は、仮想 IP アドレスを代替システムに「移動」させることを意味します。テレフォニーアプリケーションサーバーまたは Media Server を高可用性クラスタにインストールする場合、 テレフォニーアプリケーションサーバーまたは Media Server は、仮想 IP アドレスを使用してインストールされます。 テレフォニーアプリケーションサーバー/Media Server は、仮想 IP アドレスを使用して開始されます。テレフォニーアプリケーションサーバーに障害が発生し、SAMP が同じノード上で再起動できない場合、 SAMP は、仮想 IP アドレスを既存のノードから切り離して、スタンバイノードに切り替えます。

移動が完了すると、マウントするデータポイントと、これらのデータポイントの実際のマウントがポリシーによって指定されます。

次に SAMP は、自動化ポリシーで定義された関係とリソースを使用して、各アプリケーションの開始方法、およびそれらのアプリケーションの開始順序を決定します。

ポリシーには、アプリケーションの停止に必要な情報も含まれています。

Sametime Unified Telephony 固有の SAMP スクリプト

IBM Sametime Unified Telephony の高可用性クラスタをセットアップしたときの成果物を以下に示します。

  • 自動化ポリシーを生成するスクリプト。
  • ポリシー生成スクリプトで使用される応答ファイル。
  • SAN マウントを処理するスクリプト。このスクリプトは、sutctrl-data.sh と呼ばれます。
  • コマンドの開始、停止、モニターを含めて Sametime Telephony ソフトウェアをモニターするスクリプト。
  • SAMP で WebSphere Application Server を制御できるようにするスクリプト

SAMP ドメインを定義する XML 自動化ポリシーに関連付けられたファイルを受信することになります。 複数のサンプルポリシーを受信しますが、より重要なことは、ご使用の環境に固有の自動化ポリシーを生成するスクリプトを受信することです。 このスクリプトは、generateAutomationPolicy.sh と呼ばれます。 このスクリプトを使用するには、最初に応答ファイルを作成する必要があります。 応答ファイルには、各 TAS に関する情報 (TAS マウントポイント ID、WebSphere Application Server マウントポイント ID、テレフォニーアプリケーションサーバーと WebSphere Application Server の仮想 IP アドレス、 SAMP ドメイン名、自動化ポリシー名など) が含まれます。 これについては、以降のトピックで詳しく説明します。

ポリシーを生成したときは、ポリシーファイルにリソース (VIPA やマウントポイントなど) が含まれていることに注意してください。 また、開始、停止、モニタースクリプトの呼び出しだけではなく、開始順序と関係も含まれています。

フェイルオーバークラスタが配置され、オンラインになると、クラスタ内のどのノードからでも、または操作コンソールを通じて、フェイルオーバークラスタをモニターおよび制御できます。 コマンドラインを使用すると、より詳細な制御と自律化が可能になります。 詳細は、公式の SAMP 資料を参照してください。

注: すべてのスクリプトは、SAMP のインストール時に自動的にインストールされます。 マウントポイント、TAS、WebSphere Application Server を制御するスクリプトは、以下のディレクトリにあります。
/usr/sbin/rsct/sapolicies/SUT
自動化ポリシー (および、関連する応答ファイル) を生成するスクリプトは、以下にあります。
/software/IBM/Failover/tools
デプロイメントの概要

IBM Sametime Unified Telephony の使用可能なデプロイメントには、Media Server のデプロイ方法に応じて、オンボードオフボード の 2 種類があります。

オンボードデプロイメント

オンボード デプロイメントの場合、すべての機能エレメントが同じマシン上に存在します。 例えば、Sametime Telephony ソフトウェア、Sametime Unified Telephony 固有のアプリケーション、Media Server がすべて同じコンピュータ上に存在します。このタイプのデプロイメントの場合、各テレフォニーアプリケーションサーバーが使用できるのは、同じコンピュータ上にホストされている Media Server だけであるため、会議サービスに関する拡張性の問題が存在します。 オンボード インストールでは、インストール応答ファイルが 1 つのみ存在します。

オフボードデプロイメント

オフボード デプロイメントの場合、Sametime Telephony Software と Sametime Unified Telephony 固有のアプリケーションは同じコンピュータ上に存在しますが、Media Server は個別の専用コンピュータ上に存在します。このデプロイメントは、顧客の会議要件とアナウンス要件に応じて、テレフォニーアプリケーションサーバーごとに複数の Media Server をサポートします。オフボード のインストールでは、各 Media Server とテレフォニーアプリケーションサーバー用に、個別のインストール応答ファイルが用意されています。

次のセクションでは、可能なデプロイメントのいくつかについて概説します。

オンボードデプロイメントの例

オンボードデプロイメントは、使用可能な最小の高可用性デプロイメントを提供します。

このケースでは、単一のテレフォニーアプリケーションサーバーコンピュータ、標準の二重のテレフォニー制御サーバー、単一のスタンバイサーバーが存在するオンボード デプロイメントについて考えてみます。

1 次ノードには、クラスタソフトウェア (SAMP)、テレフォニーアプリケーションサーバーソフトウェア、組み込み Media Server がインストールされています。 スタンバイサーバーとオペレーティングシステムが稼働しており、 クラスタソフトウェアがアクティブにノードをモニターしています。データベースとすべての構成データ (IBM WebSphere Application Server バイナリやテレフォニーアプリケーションサーバーバイナリなど) は、SAN (ストレージエリアネットワーク) に保管されます。 ハードウェアプロファイルは、両方のサーバーで同じでなければなりません。ソフトウェアは、SAN ドライブに完全にインストールされています。

SAMP 操作コンソールは、クラスタ内のどのシステムにもインストールされません。その代わりに、別個のサーバーにインストールされます。SAMP は、基本コンポーネント自動化アダプタがクラスタノード上で構成されると、クラスタの概要を表示します。障害が発生した場合、SAMP は、稼働中のテレフォニーアプリケーションサーバーコンポーネントをすべて停止します。 次に、仮想 IP アドレスとマウントポイントが 1 次ノードから切り離され、 スタンバイノード上で再アクティブ化されます。 テレフォニーアプリケーションサーバーコンポーネントは、スタンバイノード上で再起動されます。

単一テレフォニーアプリケーションサーバーを使用したオンボードデプロイメント

次の図では、より現実的な実環境のフェイルオーバークラスタを説明します。このケースでは、単一のスタンバイサーバーが存在する、複数のテレフォニーアプリケーションサーバーのオンボード デプロイメントを示します。このスタンバイサーバーは、いずれかのテレフォニーアプリケーションサーバーで障害が発生した場合に使用可能になります。

各 1 次ノードにはクラスタソフトウェアがインストールされており、スタンバイサーバーが稼働しています。前のシナリオと同様、データベースとすべての構成データ (WebSphere Application Server バイナリやテレフォニーアプリケーションサーバーバイナリなど) は、SAN に保管されます。

各テレフォニーアプリケーションサーバーのアプリケーションデータは、別個の SAN LUN (論理装置番号) に保管されます。 LUN は、SAN の特定のディスク領域を指す番号です。

テレフォニーアプリケーションサーバーのいずれかに障害が発生した場合、SAMP は、特定のマウントポイントを解放し、関連する SAN ディスク LUN を使用して、それらのマウントポイントをスタンバイノード上で再アクティブ化します。

数のテレフォニーアプリケーションサーバーを使用するオンボードデプロイメント

オフボードデプロイメント

このセクションでは、2 つのオフボード デプロイメントのシナリオを示します。これらのシナリオでは、Media Server が専用のコンピュータ上に存在しています。

以下の図は、フェイルオーバーに対応した包括的なオフボード 環境を示しています。 このデプロイメントでは、複数のテレフォニーアプリケーションサーバーと複数の Media Server を使用していますが、スタンバイノードは 1 つしか使用していません。 このスタンバイノードは、テレフォニーアプリケーションサーバーであろうと、Media Server であろうと、 クラスタ内のどのノードからも引き継ぎを行えるように構成されています。

各 1 次ノードには、クラスタソフトウェアがインストールされています。 スタンバイサーバーが稼働中で、クラスタソフトウェアがノードをモニターしています。このシナリオでは、Media Server のアプリケーションデータを含むすべてのアプリケーションデータが SAN (ストレージエリアネットワーク) に保管されます。

テレフォニーアプリケーションサーバーまたは Media Server のいずれかで障害が発生した場合、SAMP は特定のマウントポイントを解放し、関連する SAN ディスク LUN (論理装置番号) を使用して、それらのマウントポイントをスタンバイノード上で再アクティブ化します。これにより SAMP は、スタンバイノード上でアプリケーションを再起動できるようになります。 この時点で、障害が発生した 1 次ノード上で保守を実行することが可能です。

最初のオフボード デプロイメント

次のシナリオでは、複数のスタンバイノードを使用します。このシナリオでは、障害が発生した場合、どのアクティブなテレフォニーアプリケーションサーバーまたは Media Server でも、任意のスタンバイノードに切り替わることができます。 これは、柔軟性が非常に高いフェイルオーバーモデルです。

2 番目のオフボード デプロイメント
フェイルオーバーのユースケースの説明

フェイルオーバーシナリオでは、以下のユースケースが検討されています。

  • スタンバイノードへのフェイルオーバー
  • 元のシステムへの切り替え
  • フェイルオーバークラスタ上でのソフトウェアの更新

これらの各シナリオについては、以降のそれぞれのセクションで詳しく説明します。 各セクションでは、高可用性 SAMP クラスタを日々管理する中で発生する場合のある特定のフェイルオーバーシナリオについて概説します。

スタンバイノードへのフェイルオーバー

このセクションでは、システムがフェイルオーバーする原因と、フェイルオーバーの実行方法について説明します。

目標:

重大な障害状態を検出して、スタンバイノードへのフェイルオーバーを開始します。

前提条件:
  • SAMP ソフトウェアがすべてのノード (アクティブノードとスタンバイノードの両方) にインストールされており、完全に機能していること (テレフォニーアプリケーションサーバーコンポーネントや WebSphere Application Server コンポーネントなどの 重要なアクティブソフトウェア成果物をモニターしていること)。
  • スタンバイノード、操作システム、クラスタソフトウェアが稼働していること。
  • データベースとすべての構成データが共有ストレージシステム (SAN) に保管されていること。
  • ハードウェアプロファイルがすべてのノードで同じであること。
  • ソフトウェアが SAN ドライブに完全にインストールされていること。
  • Media Server のインストール済み環境については、TAS コンポーネントのサブセットのみがインストールされていること。 例えば、データベースは使用されません。
説明:
  • SAMP は、重大な障害状態を検出して、スタンバイノードへの切り替えを決定します。
  • 偽の障害状態 (計画シャットダウンなど) は除外する必要があります。
  • システムは、実行中のすべてのソフトウェア成果物とデータベース (使用している場合) をシャットダウンして、 共有ファイルシステムを解放 (アンマウント) し、アクティブ/障害ノードから仮想 IP アドレスを解放することを試みます。
  • システムは、障害ノードの正常シャットダウンを試みます。ただし、それが不可能の場合は、 強制シャットダウンを実行します (OS レベル)。
  • 「外部」IP アドレス (仮想 IP アドレスなど) を再構成またはアクティブ化して、 スタンバイノードを SUT クライアント用に使用できるようにします。
  • システムは再び完全に動作するようになり、スタンバイノードは破壊/障害ノードに置き換わります。 クライアント/サービス利用者の視点から見ると、システム/クラスタは、再起動された単一ノードのように動作します。
  • 他のノードのクライアント/サービス利用者は、新しいサーバーノードへの接続を再確立します。
事後条件:
  • システムは、(スタンバイノード上で) 再び完全に動作します。
  • クライアントおよび他のサービスは、切り替え前と同じ IP アドレス (例えば、仮想 IP アドレス) を使用して、 システムに接続できます。
  • 障害が発生したノードは、動作を停止するか、OS のみをアクティブにして稼働します (例えば、SAMP リソースは、FAILED OFFLINE 状態です)。 障害が発生したノードハードウェアとオペレーティングシステム (OS) にサービスを提供することも (例えば、OS パッチの適用)、 OS を再インストールすることも可能です (これは、ハードディスクのクラッシュ後などに必要です)。 ただし、テレフォニーアプリケーションサーバーが別のノード上でアクティブの間は、 スタンバイノード上のテレフォニーアプリケーションサーバーソフトウェアの更新やパッチ適用を行うことはできません。 テレフォニーアプリケーションサーバーソフトウェアの更新はすべて、初期インストールを実行した物理的なシステム上で行う必要があります。
注: スタンバイノード上で更新を行うことはできません (インストールノードとスタンバイノード間で RPM データベースに不整合が生じます)。 システムを更新するには、最初にインストールされたノードへの切り替えが必要です。
元のノードへのフェイルバック

このセクションでは、何らかのエラー条件のためにスタンバイにフェイルオーバーしたシステムを元のノードに戻すことができる場合に、 管理者が手動で行うタスクについて説明します。

目標:

元のノードが再び動作する。

作業者:

管理者

前提条件:

以前障害が発生したシステムが修復され、再び動作できるようになっています。

説明:

管理者がクラスタソフトウェアを手動で (例えば、コマンドラインインターフェースを使用して) 起動し、 他方のノードに切り替えます。 これを行う方法の詳細については、以降のセクション 「フェイルオーバークラスタのインストール」を参照してください。

事後条件:

他方のノードがアクティブであり、以前アクティブだったノードは再度スタンバイノードになります。 システムは再び完全に動作します。

フェイルオーバークラスタ上でのソフトウェアの更新

これは、管理者が手動で行うタスクです。

目標:

インストールしたソフトウェアのバージョンをクラスタ全体で確実に一貫させます。

作業者:

管理者

前提条件:

以前障害が発生したシステムが修復されており、再び動作できるようになっています。

説明:
  • 管理者は、更新インストール時の対話を防止するために SAMP ソフトウェアを「手動」モードに設定します。
  • 更新は、ソフトウェアを最初にインストールしたシステム上で実行する必要があります。 なぜなら、rpm データベースは、その特定のノード上でのみ更新されるからです。
  • 管理者は、テレフォニーアプリケーションサーバーソフトウェアを停止して、 単一ノードシステム上で通常行うのと同じ方法でソフトウェアを更新します。
  • 更新中、システムはオフラインです。 管理者は、SAMP の手動モードをオフにして、クラスタソフトウェアを再びアクティブ化します。 その結果、SAMP により、テレフォニーアプリケーションサーバーソフトウェアが再起動します。
事後条件:
  • システムは再び完全に動作します。
  • スタンバイノードが稼働しており、アクティブノードで障害が発生した場合に引き継ぎを行う準備が整っています。
クラスタの例

このセクションでは、典型的なフェイルオーバーインストール済み環境をグラフィカルに示します。

以下の図は、3 つのノードが別々のアプリケーション (TAS1 (テレフォニーアプリケーションサーバー)、MediaServer1、MediaServer2) を稼働しているシナリオの例を示しています。 両方の Media Server は、会議チャネルとトーンチャネルを提供するように構成されています。 各アプリケーションは、障害が発生した場合にスタンバイノードに切り替えることができます。

クラスタの例

SAMP リソースモデル

すべての SAMP リソースおよび依存関係は、XML に基づく SAMP ポリシーファイルで定義されます。

SAMP ポリシーには、以下の内容が記述されます。

  • アプリケーションでモニターされるすべてのリソース、およびリソース間の依存関係。
  • IP アドレスを含むネットワークインターフェース。
  • 仮想 IP アドレス。
  • タイブレーカ。このケースでは、ネットワークタイブレーカは、デフォルトゲートウェイの IP アドレスと共に使用されます。

以下の図は、テレフォニーアプリケーションサーバー/Media Server のインストール済み環境でリソースグループレベルで使用される リソースモデル化を示しています。

モデル 1

BASE_TAS リソースグループと BASE_MS リソースグループはそれぞれ、SAN ディスク (/enterprise) にファイルシステムをマウントするリソースと仮想 IP アドレス (VIPA) を割り当てるリソース、およびテレフォニーアプリケーションサーバーまたは Media Server のいずれかから構成されます。

NODE_MGR_TAS は、以下のリソースから構成されます。

  • OSGi コンテナ (必須)
  • サーブレットコンテナ/Tomcat (必須)
  • ActiveMQ (必須)
  • SNMP レシーバ (任意)
  • 通知マネージャ (任意)

NODE_MGR_MS は、以下のリソースから構成されます。

  • OSGi コンテナ (必須)
  • 通知マネージャ (任意)

DB_MGR_TAS には、ソリッドデータベースのリソースのみが含まれます。

正常に機能するために NODE_MGR_TAS では、同じノードで稼働中の DB_MGR_TAS (「StartsAfter」および「Collocated」関係)、 および BASE_TAS によって提供される割り当て済みの仮想 IP アドレスとマウント済みファイルシステム (「DependsOn」関係) が必要です。 NODE_MGR_MS では、同じノード上で BASE_MS が提供する割り当て済みの仮想 IP アドレスとマウント済みファイルシステムが必要です (「DependsOn」関係)。また、Media Server は、データベースを含むテレフォニーサーバーの後に開始する必要があります (MS「StartsAfter」TAS)。 オフボード Media Server とテレフォニーアプリケーションサーバーが常に別々のノード上で稼働することを保証するために、 BASE_MS リソースグループと BASE_TAS リソースグループは「AntiCollocated」として定義されています。

WebSphere Application Server を含む SAMP リソースモデル

WebSphere Application Server (WAS) を処理するには、以下のリソースモデルを適用する必要があります。

モデル 2

NODE_MGR_WAS リソースグループは、単一のリソース (WebSphere Application Server) から構成されます。

この SAMP リソースモデルでは、制限された「DependsOn」関係しか存在しません。 「DependsOn」には「ForcedDownBy」関係も含まれているので、 リソース B がダウンした場合にリソース A が停止されます (例えば、BASE_TAS がダウンした場合に NODE_MGR_TAS が停止されます)。 WebSphere Application Server は、テレフォニーアプリケーションサーバーとは無関係に停止できますが、 テレフォニーアプリケーションサーバーより前に開始する必要があります (「StartAfter」)。 WebSphere Application Server は、TAS と同じノード上で稼働する必要があります (「Collocated」(双方向で))。 WebSphere Application Server とテレフォニーアプリケーションサーバーの BASE_xxx リソース (マウントポイントと仮想 IP アドレス) は、 同じノード上で稼働する必要があります (「Collocated」)。

注: これらの SAMP の関係の詳細については、公式の SAMP サイトにある SAMP の管理者向けガイドを参照してください。
http://www-01.ibm.com/software/tivoli/products/sys-auto-multi/
フェイルオーバークラスタのインストール

IBM Tivoli System Automation を使用して、IBM Sametime Unified Telephony デプロイメントのフェイルオーバークラスタを セットアップします。

前提条件のセットアップ

以下のサブセクションでは、IBM Sametime Unified Telephony デプロイメントにフェイルオーバークラスタを インストールする前に満たす必要のある前提条件を詳しく説明しています。

仮想 SAN のディスクパーティションの設定

仮想デプロイメントの SAN (ストレージエリアネットワーク) として機能する物理ハード・ディスクをパーティションで区切ります。

このタスクについて

テレフォニーアプリケーションサーバーとして機能する 2 つの仮想マシン (「VM_TAS1」と「VM_TAS2」) をセットアップし、仮想ストレージエリアネットワーク向けのハードウェアのセットアップの説明に従って、仮想 SAN として機能する共有ディスクが作成されているとします。

手順
ディスクをパーティションで区切るには、VM_TAS1 または VM_TAS2 にログインし、2 つのパーティションを作成します。

これらのパーティションは、SAMP ポリシー内の /enterprise ディレクトリと /opt/IBM/WebSphere ディレクトリによって使用されます。

[yast] > [System] > [Partitioner]コマンドを使用して、ディスクをパーティションで区切ることができます。パーティションは、「物理 SAN の設定」で説明している物理 SAN の仕様に従って作成する必要があります。yast パーティショナーにより、これらの新しいパーティションが自動的に /etc/fstab に追加されます。

物理 SAN の設定

このトピックでは、物理 SAN (ストレージエリアネットワーク) をセットアップするための要件を説明します。フェイルオーバークラスタのインストールを続行する前に、必ずこのタスクを実行してください。パーティションの作成に関する情報は、物理 SAN と仮想 SAN の両方に適用されます。

このタスクについて

SAN とは、ストレージエリアネットワークのことです。 FC インストール手順を通じてアクセスされるディスクアレイは、このトピックの範囲外です。

それぞれのアクティブなテレフォニーアプリケーションサーバーでは、SAN 上に 2 つ LUN (論理装置番号) が必要であり、合計 30 GB のディスクスペースが必要です。
  • /enterprise - 20 GB のディスクスペースが必要
  • /opt/IBM/WebSphere - 10 GB のディスクスペースが必要
スタンバイテレフォニーアプリケーションサーバーは、ディスクスペース要件に関してはカウントに含めません。例えば、デプロイメントに 1 つのアクティブなテレフォニーアプリケーションサーバーと 1 つのスタンバイテレフォニーアプリケーションサーバーが含まれる場合は、SAN 用に合計 30 GB のディスクスペースが必要になります。

オフボード Media Server では、SAN (/enterprise) 上に 1 LUN のみ必要であり、20 GB のディスクスペースが必要です。

手順
  1. SAN の構成
    1. SAN がインストールされ、構成されています。
    2. SAN LUN を構成します。
      • LUN: 論理装置番号。
    3. SAN は、ストレージマネージャと呼ばれるユーティリティを使用して構成します。
      • ストレージマネージャを使用して、新しい論理ドライブを作成し、LUN マッピングに対する論理ドライブ名を表示します。
      以下に示すのは、テレフォニーアプリケーションサーバー、および別個の Media Server LUN マッピングテーブルの例です。
      注: テレフォニーアプリケーションサーバー用に 2 LUN、別個の Media Server 用に 1 LUN 使用しています。
      例
    4. テレフォニーアプリケーションサーバーノードごとに 30 GB、Media Server ノードごとに 20 GB のサイズを持つ論理ドライブを SAN 上に作成する必要があります。このタスクの実行方法については、SAN 製造元のマニュアルを参照してください。
    5. HBA カードを各ホストシステム (スタンバイノードを含む) にインストールします。
      • HBA: ホストバスアダプタ。 ファイバーチャネルを通じて SAN または SAN スイッチにアクセスするためにホストに取り付ける PCI カード。
      • 取り付け手順はこのセクションの範囲外ですが、別のセクション「SAN デプロイメント」には、 HBA カードの詳しい構成手順が記載されています。
    6. ノードを SAN に接続します。
  2. 関連するディレクトリが各ノード上に存在することを確認します。 すべてのスタンバイノードを含むクラスタ内のすべてのノード上に以下のディレクトリを作成します (ディレクトリ名には、大/小文字の区別があります)。
    /enterprise 
    /opt/IBM/WebSphere 
  3. /etc/fstab ファイルにマウントポイントを追加します。

    インストール手順を引き続き開始する前に、すべてのシステム上にマウントポイントを準備して、 テレフォニーアプリケーションサーバーまたは Media Server の /enterprise パーティションを任意のノード上にマウントできるようにし、 同様に /opt/IBM/WebSphere を WebSphere Application Server の任意のノード上にマウントできるようにする必要があります。

    デバイス名は、SAN のパーティショニングに応じて適合させる必要があります。 それぞれの TAS または Media Server のインストール済み環境では、/enterprise マウントポイントが使用されているので、 /etc/fstab ファイルにマウントポイント /enterprise のエントリがいくつか存在しますが、 すべて異なるデバイスを持ちます。
    注: fstab ファイルには、クラスタ内の各アクティブノードのエントリが含まれている必要があります。 以下の例は、2 つの TAS、2 つの Media Server、1 つのスタンバイノードを含むクラスタのサンプル fstab ファイルを示しています。
    /dev/disk/by-id/scsi-3600a0b8000496cbe0000025348ce2b6c	/enterprise 
    ext3       noauto,acl,user_xattr 1 0
    /dev/disk/by-id/scsi-3600a0b8000496cbe0000025448ce2b80
    /opt/IBM/WebSphere	ext3       noauto,acl,user_xattr 1 0
    /dev/disk/by-id/scsi-3600a0b8000496cbe0000025548ce2b92       
    /enterprise		 ext3       noauto,acl,user_xattr 1 0
    /dev/disk/by-id/scsi-3600a0b8000496cbe0000033a48f5f0e4         
    /enterprise             		 ext3       noauto,acl,user_xattr 1 0
    /dev/disk/by-id/scsi-3600a0b8000496cbe0000033b48f5f102         
    /opt/IBM/WebSphere	 ext3       noauto,acl,user_xattr 1 0
    /dev/disk/by-id/scsi-3600a0b8000496cbe0000033c48f5f11c         
    /enterprise             		 ext3       noauto,acl,user_xattr 1 
    重要なことは、マウントは自動的に実行されないことです。 つまり、リブート後にシステムはマウントを実行しません (noauto オプション)。 また、値 0 を最後の列に設定する必要があります。 これにより、このマウントポイントについて、ファイルシステムの検査が自動的に実行されなくなります。 そうしないと、ファイルシステムが別のノード上にマウントされたとしても、また ファイルシステムが自動的にマウントされないとしても、 リブート後にスタンバイノード上でファイルシステムの検査が開始される可能性があります。 このイベントが発生した場合、fsck は失敗し、ノードは正しくインストールされません。 エディタを使用して、例に従って /etc/fstab を変更します。
  4. /etc/fstab 設定を検査します、
    続行する前に、すべてのノード上でマウントが正しく機能していることを確認します。 決して複数のノード上に同じマウントポイントを同時にマウントしないように注意してください。 最初のノードにログオンし、インストール済み環境のデバイス名を使用するように注意して、 以下を呼び出します。
    mount /dev/disk/by-id/scsi-3600a0b80003aafbc00003cf44897ad68-part1
    システムが正しくマウントされている場合は、オプションを指定せずに mount コマンドを呼び出すことにより、システムを検査できます。 マウントされているデバイスが出力されるはずです。
その他の前提条件

このセクションでは、フェイルオーバークラスタのインストールを続行する前に満たすことが 必要な、SAN 以外に関連する他の要件について説明します。

追加 IP アドレス
  • テレフォニーアプリケーションサーバーあたり 1 つまたは 2 つの追加 IP アドレス
    • WebSphere Application Server とテレフォニーアプリケーションサーバーが同じ IP アドレス上に存在する場合は、 1 つの追加 IP アドレス
    • WebSphere Application Server とテレフォニーアプリケーションサーバーに固有の IP アドレスがある場合は、 2 つの追加 IP アドレス
  • オフボード Media Server あたり 1 つの追加 IP アドレス
ホストシステムの構成
各ノード上で、以下の行が含まれるように /etc/hosts ファイルを変更します。
127.0.0.2       localhost.localdomain localhost
ダウンロード

ダウンロードプロセスについては、セクション「テレフォニーアプリケーションサーバーのインストールパッケージのダウンロード」で詳しく説明します。次のステップに従ってください。

  • テレフォニーアプリケーションサーバーにバンドルされるソフトウェアインストーラを software/IBM ディレクトリにダウンロードします。
  • テレフォニーアプリケーションサーバーまたは Media Server のすべての前提条件をローカルの /software/IBM ディレクトリにダウンロードします。
  • tar ファイルを抽出します。
     tar xvfz file_name.tgz
    例:
     tar xvfz CZJJ1ML.tgz 
  • すべてのメディアが /software/IBM ディレクトリに抽出されたことを確認します。
  • 抽出されたメディアには、関連するすべてのソフトウェアが含まれています (クラスタソフトウェア SAMP、 テレフォニーアプリケーションサーバーソフトウェア、IBM WebSphere Application Server、スクリプトなど)。
SAMP のインストール

IBM Sametime Unified Telephony デプロイメントへのテレフォニーアプリケーションサーバーのインストールを開始する前に、 IBM Tivoli System Automation for Multiplatforms (SAMP) 基本コンポーネントをインストールします。

始める前に

前提条件がすべて満たされていること、およびすべてのメディアが /software/IBM にダウンロード されていることを確認します。 Tivoli SAMP V3.1 基本コンポーネントは、テレフォニーアプリケーションサーバーのインストールパッケージに含まれています。

このタスクについて

SAMP V3.1 基本コンポーネントのインストールの詳細については、 『インストールおよび構成のガイド』を参照してください。

手順
  1. root としてサーバーにログインします。
  2. /software/IBM ディレクトリに移動します。
  3. 次のコマンドを実行して、SAMP をインストールします。
    ./installSAMP.sh
    SAMP 基本コンポーネントがインストールされます。
  4. SAMP 基本コンポーネントのインストールが完了したら、etc/profile を編集して、 以下の行を追加します (この行は、ファイルの終わりに配置できます)。
    export CT_MANAGEMENT_SCOPE=2
  5. CT_MANAGEMENT_SCOPE 環境変数を各ノード上で明示的に設定します。 端末ウィンドウから以下のコマンドを起動します。
    export CT_MANAGEMENT_SCOPE=2
SAMP クラスタの作成

このトピックでは、SAMP 論理クラスタを作成するために起動する必要のあるコマンドをすべて説明します。

手順
  1. クラスタのすべてのノード上で以下のコマンドを発行します。
    	preprpnode node1 node2 nodeN
    コマンドには、各ノード名を指定します。
  2. 1 つのノード上でのみ以下のコマンドを実行して、ノードを収容するドメインを作成します。
    mkrpdomain DOMAIN_NAME node1 node2 nodeN 		
    注: DOMAIN_NAME には、どのような名前でも選択できます。
  3. 任意のノードからドメインを開始します。
    startrpdomain DOMAIN_NAME
  4. ドメインが稼働中であることを確認します (このコマンドは、どのノードからでも再度起動できます)。
    lsrpdomain
    正常に定義された SAMP クラスターの出力は次のようなテキストになります。
    tas1:~ # lsrpdomain
    Name OpState RSCTActiveVersion MixedVersions TSPort GSPort
    tastest Online 2.5.5.8 No 12347 12348 
  5. ノードがオンラインであることを確認します。
    lsrpnode
    ノードがオンラインのときは、応答は次のようなテキストになります。
    tas1:~ # lsrpnode
    Name OpState RSCTVersion
    tas1 Online 2.5.5.8
    tas1a Online 2.5.5.8 
  6. すべてのノード上でタイブレーカを定義します。

    タイブレーカは、ノード数が偶数のクラスタで必要です。 タイブレーカがないと、SAMP は、クラスタ内の半分を超えるノードがオンラインになったときにのみリソースを自動化します。 したがって、2 ノードクラスタの場合、リソースを自動化するには、両方のノードがオンラインになる必要があります。 ここでの目的のため、すべてのノード上でタイブレーカを作成する必要があります。

    1. /var の下に以下のディレクトリを作成します。
      • /cf
      • /cf/cfg
    2. /var/cf/cfg 内にファイル netmon.cf を作成します (このファイルは、すべてのノード上で作成します)。

      タイブレーカ の詳細については、TSA の資料を参照してください。

    3. netmon.cf ファイルには、タイブレーカとして使用する必要のあるホストの IP アドレスが含まれます。

      この目的のためには、デフォルトゲートウェイを使用することをお勧めします。 ただし、すべてのシステムから (いつでも) アクセス可能なサブネット内の任意の IP アドレスで十分です。

      デフォルトゲートウェイが 9.192.192.1 であるサンプルの netmon.cf ファイルの内容は、 以下のようになります。
      #This is default gateway for all interfaces in the subnet 9.192.192.0 
      9.192.192.1
    4. このプロセスを繰り返して、すべてのノード上でタイブレーカを定義します。
自動化ポリシー応答ファイルの編集

AutomationPolicyResponseFile_Onboard.txt ファイル、または AutomationPolicyResponseFile_Offboard.txt ファイルを変更して、 IBM Sametime Unified Telephony デプロイメントに適した値を指定します。

このタスクについて
自動化ポリシー応答ファイルを使用して、デプロイメントのテレフォニーアプリケーションサーバーと オフボード Media Server を構成します。 自動化ポリシー応答ファイルには、以下の 2 つがあります。
  • AutomationPolicyResponseFile_Onboard.txt: 各 Media Server をテレフォニーアプリケーションサーバーに直接インストールする オンボードデプロイメントでは、このバージョンのファイルを使用します。
  • AutomationPolicyResponseFile_Offboard.txt: 各 Media Server をテレフォニーアプリケーションサーバーとは別個にインストールするオフボードデプロイメントでは、 このバージョンのファイルを使用します。 このバージョンのファイルには、オフボード Media Server 専用で使用される追加設定が含まれています。
2 つの典型的なデプロイメント用にサンプルの自動化応答ファイルが用意されています (これらのファイルは、/software/IBM/Failover/tools にあります)。
  • SampleResponsefile_1TAS_1Standby.txt: このサンプルは、単一のアクティブなテレフォニーアプリケーションサーバーと単一のスタンバイサーバーをデプロイするという 最も単純なシナリオを表しています。 このサンプルは、AutomationPolicyResponseFile_Onboard.txt ファイルに基づいています。
  • SampleResponsefile_2TAS_2MS_2Standby.txt: このサンプルは、2 つのアクティブなテレフォニーアプリケーションサーバー、2 つのスタンバイサーバー、2 つのオフボード Media Server を含むクラスタから構成されるより複雑なシナリオを表しています。 このサンプルは、AutomationPolicyResponseFile_Offboard.txt ファイルに基づいています。
手順
  1. /software/IBM/Failover/tools ディレクトリにナビゲートし、 テキストエディタで AutomationPolicyResponseFile_Onboard.txt ファイル、 または AutomationPolicyResponseFile_Offboard.txt ファイルを開きます。

    使用するのはいずれか一方のファイルのみですが、これは、オンボード Media Server とオフボード Media Server の どちらを使用するのかによって決まります。

  2. スクリプトで、すべての CRLFLF に置き換えて、スクリプトが適切に実行されるようにします。
  3. 以下の一般フィールドを入力します。これらは、必須フィールドです。
    表 1. 必須の一般フィールド
    フィールド 説明
    ポリシー名 自動化ポリシーの名前。 これは、自動化ポリシーをアクティブ化するために次のステップで使用するポリシー名です。
    ドメイン名 ステップ 2 で「mkrpdomain」コマンドを使用して SAMP クラスタを作成したときに定義した名前。
    スタンバイノード (Standby Node) クラスタ内のすべてのノードに単一のスタンバイノードが存在する場合は、 [スタンバイノード (Standby_Node)] にホスト名を入力します。 クラスタに複数のスタンバイノードが存在する場合は、すべてのスタンバイサーバーのホスト名をコンマで区切って入力します。
    注: ノードのホスト名には、短縮ホスト名のみを使用してください。 例えば、ノードの完全修飾ドメイン名が host123.zyx.com の場合、短縮ホスト名は host123 になります。
    TAS_Network_ Interface 仮想「浮動」IP アドレスをホストするネットワークインターフェースを定義する必要があります。 WebSphere Application Server とテレフォニーアプリケーションサーバーが同じ IP アドレスを使用している場合は、 TAS_Network_Interface の値のみを入力します。 通常、ネットワークインターフェースの値は、「eth0」や「eth1」などです。 また、アダプタを結合して使用している場合は、「bond0」などの値が使用されます。
    注: アダプタを結合すると、ネットワーク切り替えのために、フェイルオーバー条件の可能性が減少します。 結合したアダプタのセットアップ方法については、SAN デプロイメントについて記述されたセクションを参照してください。
    WAS_Network_ Interface WebSphere Application Server が別個の IP アドレスを持つ場合は、 ここに WebSphere Application Server 仮想 IP アドレスの値を入力します。
    Tie_Breaker タイブレーカは、ノード数が偶数のクラスタで必要です。 ネットワークタイブレーカは、すべてのノードが同じ IP サブネット内にあるドメインでのみ使用する必要があります。 デフォルトゲートウェイの IP アドレスを使用することをお勧めしますが、 ネットワークインフラストラクチャで仮想化されている場合は、これを使用してはなりません。 ドメイン内の各ノードから単一パスを通じてのみアクセス可能な IP アドレスを指定してください。
    ネットマスク IP アドレスのネットマスク。 この属性は、255.255.255.0 のような文字ストリングとして指定する必要があります。
  4. テレフォニーアプリケーションサーバーのフィールドを入力します。
    表 2. テレフォニーアプリケーションサーバーの必須フィールド
    フィールド 説明
    App_Type アプリケーションタイプ (受け入れられる値は TASWASMS です)。 アクティブなテレフォニーアプリケーションサーバーに関する情報を指定するので、 このセクションの値は TAS にする必要があります。
    TAS_Hostname: テレフォニーアプリケーションサーバーがインストールされているマシンのホスト名 (tas1 など)。 ホスト名を確認するには、ノード上で「host name」コマンドを実行します。
    Node_ID: インストールの ID。 対応するマウントポイント上の ID ファイルに一致する必要があります (TAS1、TAS2 など)。 この値は、ホスト名に一致する必要はありません。
    MOUNT_TAS: テレフォニーアプリケーションサーバーソフトウェアのマウントポイント。例を以下に示します。
    /dev/disk/by-id/scsi-3600a0b8000496cbe0000025378ht096
    これは、/enterprise フォルダのマップ先の値です。この値は、/etc/fstab ファイルにあります。
    VIPA_TAS: TAS の仮想 IP アドレス。 このアドレスについては、ネットワーク管理者に尋ねてください。
    App_Type アプリケーションタイプ (受け入れられる値は TASWASMS です)。 このセクションの残りの値は IBM WebSphere Application Server に適用されるので、 このセクションの値は WAS にする必要があります。
    NODE_ID インストールの ID。 対応するマウントポイント上の ID ファイルに一致する必要があります (WAS1、WAS2 など)。
    VIPA_WAS WebSphere Application Server の仮想 IP アドレス。
    注: テレフォニーアプリケーションサーバーと WebSphere Application Server が同じ IP 上に存在する場合は、これをブランクのままにします。
    MOUNT_WAS テレフォニーアプリケーションサーバーソフトウェアのマウントポイント。
    /dev/disk/by-id/scsi-3600a0b8000496cbe0098630jhf09823
    これは、/opt/IBM/Websphere フォルダのマップ先の値です。 この値は、/etc/fstab ファイルにあります。
    WAS_USERNAME このノードの WebSphere Application Server 管理者アカウントのユーザー名を指定します。
    WAS_PASSWORD このノードの同じ WebSphere Application Server 管理者アカウントのパスワードを指定します。
  5. デプロイメントのアクティブなテレフォニーアプリケーションサーバーごとに、 テレフォニーアプリケーションサーバーセクションのコピーを作成し、必要に応じて編集します。
    注: 応答ファイルにスタンバイサーバーのセクションはありません。 アクティブノードのみが含まれています。
  6. (オフボードのみ) オフボード Media Server の値を入力します。

    このセクションは、オンボードデプロイメントでは不要のため、 AutomationPolicyResponseFile_Offboard.txt ファイルにのみ存在します。

    表 3. オフボード Media Server の必須フィールド
    フィールド 説明
    App_Type アプリケーションタイプ (受け入れられる値は TASWASMS です)。 オフボード Media Server に関する詳細情報を指定するので、このセクションの値は MS にする必要があります。
    MS_Hostname Media Server がインストールされているマシンのホスト名 (ms1 など)。
    Node_ID インストールの ID。 対応するマウントポイント上の ID ファイルに一致する必要があります (MS1、MS2 など)。
    VIPA_MS Media Server の仮想 IP アドレス。
    MOUNT_MS Media Server ソフトウェアのマウントポイント (/dev/disk/by-id/scsi-3600a0b8000496cbe0098098432h)
  7. デプロイメントのオフボード Media Server ごとに、 オフボード Media Server セクションのコピーを作成し、必要に応じて編集します。
以下に示すのは、1 つのテレフォニーアプリケーションサーバー、1 つのスタンバイサーバー、1 つのオフボード Media Server から構成されるクラスタの自動化ポリシーの例です (AutomationPolicyResponseFile_Offboard.txt ファイルを使用)。
#######################################################################
# 一般ドメインの詳細。ここでは、自動化ドメインの名前
と
# ドメインを構成するすべてのノード (スタンバイノードを含む) の名前が必要です。 # また、
ネットワーク同等物とネットワークタイブレーカ
# も含まれます
#######################################################################
# 自動化ポリシーファイルの名前を指定します
Policy_Name: SUT_Test_Policy

# フェイルオーバークラスタの名前
Domain_Name: SUT_Test

# クラスタのすべてのノード用に単一のスタンバイノードが存在する場合は、
# Standby_Node にホスト名を入力します。クラスタに複数のスタンバイノードが存在する場合は、
# すべてのスタンバイサーバーのホスト名をコンマで区切って入力します
#	スタンバイ TAS のノード名を Standby_Node に入力します
Standby_Node: host123

# ネットワークインターフェース名 (eth0 や eth1 など)
# N.B. - WAS とフレームワークが同じ IP アドレスを使用している場合は、
# TAS_Network_Interface の値のみを入力します。
#     - WAS が別個の IP アドレスを持つ場合は、
# WAS_Network_Interface の値を入力します。
TAS_Network_Interface: eth0
WAS_Network_Interface:

# デフォルトネットワークゲートウェイを入力します (192.192.192.1 など)
Tie_Breaker: 10.10.120.1

# クラスタのネットマスク
Netmask: 255.255.252.0

########################################################################

# 各セクションは、アクティブ TAS または
# アクティブ Media Server の詳細を表します。TAS サーバーには、TAS ソフトウェア
# (フレームワーク) と WAS
# ソフトウェアの両方が含まれます。したがって、TAS ノードには、TAS と WAS の
# マウントポイントと
# 仮想 IP アドレスの詳細が含まれます (TAS と WAS が別々の IP アドレス上に存在する場合、
# WAS には、VIPA のみが必要です)
# Media Server には、Media Server アプリケーションの詳細 (マウントポイント、
# 仮想 IP アドレス、
# ID など) が含まれます
#   
#N.B. - スタンバイサーバーのセクションは含めないでください
########################################################################

########################################################################
# TAS の詳細
########################################################################
# インストールのタイプ (TAS、WAS、MS など)。この場合は TAS です
App_Type: TAS

# マシンのホスト名。確認するには、ノード上でコマンド「hostname」を起動します
# (例: host123)
TAS_Hostname: tas1

# インストールの ID。対応するマウントポイント上の ID ファイルに一致する必要があります
# (例: TAS1、TAS2 など)
Node_ID: TAS1

# TAS の仮想 IP アドレス (VIPA)。
VIPA_TAS: 10.10.122.74

# TAS ソフトウェアのマウントポイント
MOUNT_TAS: /dev/disk/by-id/scsi-3600a0b8000496cbe0000025348ce2b6c

# インストールのタイプ (TAS、WAS、MS など)。この場合は WAS です
App_Type: WAS

# インストールの ID。対応するマウントポイント上の ID ファイルに一致する必要があります
# (例: WAS1、WAS2 など)
Node_ID: WAS1

# WAS の仮想 IP アドレス (VIPA)。
VIPA_WAS:

# WAS のマウントポイント
MOUNT_WAS: /dev/disk/by-id/scsi-3600a0b8000496cbe0000025448ce2b80

# このノード上の WAS のユーザー名
WAS_USERNAME: was_admin_name

# このノード上の WAS のパスワード
WAS_PASSWORD: was_admin_passw0rd

# TAS の詳細の終わり
########################################################################

########################################################################
# オフボード Media Server の詳細
########################################################################
# インストールのタイプ (TAS、MS など)
App_Type: MS

# マシンのホスト名。確認するには、ノード上でコマンド「hostname」を起動します
#Sdetermine MS_Hostname: ms1

# インストールの ID。対応するマウントポイント上の ID ファイルに一致する必要があります
Node_ID: MS1

# TAS の仮想 IP アドレス (VIPA)
VIPA_MS: 10.10.122.75

# Media Server ファイルのマウントポイント
MOUNT_MS: /dev/disk/by-id/scsi-3600a0b8000496cbe0000025548ce2b92

# Media Server の詳細の終わり
########################################################################
ポリシーの生成とアクティブ化

前に作成した応答ファイルを使用して、IBM Sametime Unified Telephony デプロイメントの自動化ポリシーを生成します。

手順
  1. 以下のコマンドを実行して、生成スクリプトが実行可能であることを確認します。
    - chmod 777 generateAutomationPolicy.pl
  2. generateAutomationPolicy.pl スクリプトを使用してポリシーを生成します。
    		./generateAutomationPolicy.pl -i automation_policy_response_file.txt  
    ここで automation_policy_response_file.txt は、 前のタスクで編集した応答ファイルです。 提供される応答ファイル用のテンプレートのいずれかを変更した場合は、 以下のいずれかの名前が使用されています。
    • AutomationPolicyResponseFile_Onboard.txt
    • AutomationPolicyResponseFile_Offboard.txt
    このコマンドの出力は、以下の例のようになります。
    Generating SAMP policy using response file: AutomationPolicyResponsefile.txt...
    ...
    Generated SAMP policy: SUT_Policy2.xml
  3. 以下のコマンドを使用して、ポリシーが有効であることを確認します。
     		sampolicy -c policy_name.xml 
  4. ポリシーが有効の場合は、以下のコマンドを使用して、ポリシーをアクティブ化します。
     		sampolicy -a policy_name.xml 
タスクの結果

ポリシーが正常にアクティブ化されると、システムは次のメッセージを出力して応答します。

Policy has been verified.


SAMP1001I: The specified policy tastest_policy.xml is valid.
EXPLANATION: The policy is valid and can be activated.
USER ACTION: None.
Are you sure you want to activate a new automation policy?
Yes(y)or No(n)?

y

..................
SAMP1003I: The policy has been activated successfully.
EXPLANATION: The policy is now active in the domain.
USER ACTION: None.
自動化ポリシーに関する注意事項

生成される自動化ポリシーに関して、以下の点に注意してください。

  • 自動化ポリシーは、上位のリソースグループから構成されます。 ドメインを制御するためには、使用される命名規則を理解する必要があります。
  • テレフォニーアプリケーションサーバーと WebSphere Application Server のマウントポイントと仮想 IP アドレスを 開始するには、以下のコマンドを起動します。
    chrg –o online SUT_BASE_TASx
    chrg –o online SUT_BASE_WASx
    ここで x はノード ID です (例えば、1、2、3...)。
  • テレフォニーアプリケーションサーバーを開始するには、ソリッド DB、テレフォニーアプリケーションサーバーフレームワーク、WebSphere Application Server を開始する必要があります。
  • テレフォニーアプリケーションサーバーを開始するには、以下のような 1 つのコマンドを起動することのみ必要です。
    chrg –o online CLUSTER_TASx 
    ここで x はノード ID です。
  • オフボード Media Server のマウントポイントと VIPA を開始するには、以下のコマンドを起動します。
    chrg –o online SUT_BASE_MediaServerX
    ここで X はノード ID です。
  • オフボード Media Server を開始するには、以下のコマンドを起動します。
    chrg –o online NODE_MGR_MediaServerX
    ここで X はノード ID です。
TAS アプリケーションのインストール

フェイルオーバーサービスをセットアップした後で、応答ファイルを準備し、IBM Sametime Unified Telephony アプリケーションをインストールします。

応答ファイルの準備

テレフォニーアプリケーションサーバーを IBM Sametime Unified Telephony デプロイメントにインストールするときに使用する応答ファイルを準備します。

始める前に

テレフォニーアプリケーションサーバーソフトウェアをインストールする前に、以下のことを実行します。

  • SUSE Linux Enterprise Server 10 SP3 がインストールされている必要があります。
  • ネットワークカードを構成する必要があります。
  • テレフォニーアプリケーションサーバーソフトウェアのインストーラ DVD があることを確認してください。
このタスクについて

応答ファイルは手動で準備する必要があります。このファイルには、IBM WebSphere Application Server のパラメータ、Sametime Unified Telephony のパラメータ、テレフォニーアプリケーションサーバーのパラメータ、solidDB のパラメータが含まれています。

使用可能な応答ファイルの形式は、オンボードオフボード のいずれのインストール済み環境を使用している、またはテレフォニーアプリケーションサーバーと Media Server のいずれをインストールするかによって異なります。テレフォニーアプリケーションサーバー IP が要求された場合は、必ずテレフォニーアプリケーションサーバー自体の IP アドレスを使用します。Media Server IP が要求される場合は、Media Server 仮想 IP アドレス (VIPA) を使用します。SIP プロキシサーバーの IP アドレスには、テレフォニーアプリケーションサーバーの仮想 IP アドレス (VIPA) を使用します。

手順
  1. Sametime Unified Telephony の応答ファイルを準備します。
    • オンボードインストールの場合は、responsefile.txt.TEMPLATE.TAS_Node_Small_Deployment ファイルを使用します。
    • テレフォニーアプリケーションサーバーのオフボードインストール済み環境の場合は、responsefile.txt.TEMPLATE.TAS_Node_Medium_Deployment ファイルを使用します。
    • オフボード Media Server インストールの場合は、responsefile.txt.TEMPLATE.Media_Server_Node_Medium_Deployment ファイルを使用します。
  2. ファイルに埋め込まれたコメントを使用して、ガイドラインに従って応答ファイルを編集します。
テレフォニーアプリケーションサーバーのインストール

テレフォニーアプリケーションサーバーをインストールするには、インストールが実行されるクラスタの 1 次ノードを選択します。

始める前に

前のトピックで responsefile.txt ファイルを適切に編集および保存しておく必要があります。

このタスクについて

インストールの後で、各マウントポイント上で ID ファイルを作成する必要があります。ID ファイルがないと、クラスタは計画したとおりに実行されません。

手順
  1. 次のコマンドを実行して、SAMP を使用してテレフォニーアプリケーションサーバーと IBM WebSphere Application Server のマウントポイントを開始します。
    chrg –o online SUT_BASE_TASx SUT_BASE_WASx
  2. 次のコマンドを使用して、手動モードでクラスタを設定します。
    samctrl -M T

    このコマンドが発行されない場合、SAN デプロイメントでのインストールは失敗します。SAMP によって別のドライブに切り替わり、予期したとおりに /opt/IBM/Websphere/ というパスの下で WebSphere Application Server 使用することができなくなるためです。

  3. Sametime Unified Telephony をインストールします。TAS インストールが実行される 1 次ノードにログオンします。新規インストールの場合:
    1. root としてログインします。
    2. ./install.sh all | tee /log/sutinst.out.log コマンドを発行して、TAS ソフトウェアをインストールします。
      注: インストール中に問題が発生する場合は、このファイルを使用して問題を調査できます。
    3. 使用許諾条件への同意を求めるプロンプトが表示されたら、yes を入力します。
    インストールには約 45 分かかります。
  4. 正常にインストールされた後で、各マウントポイント上で ID ファイルを作成します。ID ファイルは、インストール済みシステムを識別するために作成されます。ファイルの名前は、自動化ポリシー responsefile ファイル内の NODE_ID 定義と相関している必要があります。例えば、テレフォニーアプリケーションサーバーインストール済み環境は、TAS1 と呼ばれるファイルによって識別できます。WebSphere Application Server インストール済み環境は、WAS1 と呼ばれるファイルによって識別できます。Media Server インストール済み環境は、MS1 と呼ばれるファイルによって識別できます。root としてログインし、次のコマンドを実行します。
    • テレフォニーアプリケーションサーバーの場合: touch /enterprise/TAS1
    • WebSphere Application Server の場合: touch /opt/IBM/WebSphere/AppServer/WAS1。このコマンドは、サーバーを識別するための空のファイルを作成します。
    • 別個のノード上の Media Server の場合: touch /enterprise/MS1
フェイルオーバーサービスの構成

このセクションでは、TAS 上でフェイルオーバーを構成するときに必要なタスクについて説明します。

テレフォニーアプリケーションサーバーノードをオンラインに設定する

IBM Sametime Unified Telephony クラスタの 1 次ノードにテレフォニーアプリケーションサーバーソフトウェアを インストールして、マウントポイントごとに ID ファイルを作成した後、1 次 TAS ノードをオンラインに設定することが可能です。

始める前に

クラスタのマウントポイントごとに ID ファイルを作成しておく必要があります。 ID ファイルは、特定のシステムではなく、マウントしたディレクトリにのみ作成されます。

このタスクについて

ノードをオンラインに設定するには、SAMP の手動モードをオフにする必要があります。 次に、テレフォニーアプリケーションサーバーを開始して、稼働中であることを確認します。 SAMP は、開始時に実行されるプロセスを含め、すべてのクラスタコンポーネントを総合的に制御する必要があります。

手順
  1. 以下のコマンドを使用して SAMP の手動モードをオフにします。
    samctrl -M F
  2. 以下のコマンドによりテレフォニーアプリケーションサーバーを開始します。
    chrg -o online CLUSTER_TASx 
    ここで x は 1、2、3... です。ノードが Media Server の場合は、 以下のコマンドを使用します。
     chrg -o online NODE_MGR_MSX 
    ここで x は 1、2、3... です。
  3. 以下のコマンドを使用して、テレフォニーアプリケーションサーバーが開始したことを確認します。
    lssam
    「lssam」の出力例を以下に示します。
    lssam コマンド
  4. システムコンポーネント (テレフォニーアプリケーションサーバー、WebSphere Application Server、ソリッドデータベース) の自動開始を防止するために、以下のコマンドを発行します。
    		chkconfig symphoniad off
    		chkconfig solidSYM off
    		chkconfig websphere off
    スタンバイノードの「Failed Offline」状況に注意してください。
    スタンバイノードには、1 次ノードからの専用のスクリプトが必要です。 このスクリプトがないと、スタンバイノードは、ソフトウェアが復旧不能になったり、 ハードウェアに障害が発生したりした場合に、1 次ノードから引き継ぎを行うことができません。 スタンバイノードの準備については、以降のトピックで詳しく説明します。
残りのテレフォニーアプリケーションサーバーのインストールの実行

テレフォニーアプリケーションサーバーソフトウェアは、スタンバイノードを除く、 クラスタの残りのすべてのテレフォニーアプリケーションサーバー/Media Server のノードにインストールする必要があります。

このタスクについて
残りのすべてのテレフォニーアプリケーションサーバーのインストールを実行します。 これらのタスクは、クラスタのノードごとに実行することを覚えておいてください。
手順
  1. 最初にマウントポイントと仮想 IP アドレスをオンラインに設定します。 TAS1 の場合:
    chrg -o online SUT_BASE_TAS1 SUT_BASE_WAS1
    TAS2 の場合:
    chrg -o online SUT_BASE_TAS2 SUT_BASE_WAS2 (以下同様)
  2. SAMP を手動モードに設定します。
    		samctrl -M T
  3. Sametime Unified Telephony の応答ファイルを準備します。
  4. テレフォニーアプリケーションサーバーのソフトウェアをインストールします。
    		./install.sh all
  5. マウントポイント上で ID ファイルを作成します (まだ作成していない場合)。例を以下に示します。 TAS2 の場合:
    touch /enterprise/TAS2 and 
    touch /opt/IBM/WebSphere/Appserver/WAS2
  6. SAMP の手動モードをオフにします。
    		samctrl -M F
  7. テレフォニーアプリケーションサーバーを開始します。例えば、 TAS 3 の場合:
    chrg -o online CLUSTER_TAS3
  8. 以下のコマンドを起動して、テレフォニーアプリケーションサーバーコンポーネントの自動開始を防止します。
    		chkconfig symphoniad off
    		chkconfig solidSYM off
    		chkconfig websphere off
オフボード Media Server のインストール (オプション)

デフォルトでは、Media Server は IBM Sametime Unified Telephony デプロイメントの各テレフォニーアプリケーションサーバーにインストールされます。パフォーマンス向上のために、オプションで 1 つ以上のオフボード Media Server をインストールできます。

始める前に

オフボード Media Server をインストールする前に、対応するテレフォニーアプリケーションサーバーが稼働していることを確認し、knut.file.dar ファイルを生成します。このファイルを Media Server にコピーしてインストール時に使用できます。

手順
  1. 対応するテレフォニーアプリケーションサーバーが稼働していることを確認するには、 以下のコマンドを使用します。
    lssam
    または、実際のテレフォニーアプリケーションサーバーノード上で以下のコマンドを起動します。
     /etc/init.d/framework status
  2. テレフォニーアプリケーションサーバーで、以下のようにして knut.file.dar ファイルを生成します。
    1. テレフォニーアプリケーションサーバーに root としてログインします。
    2. コマンドウィンドウを開き、次のコマンドを実行します。
      ./install_tas.sh generate_dar

      knut.file.dar ファイルは /software ディレクトリに格納されます。

    3. 次のコマンドを使用して、/software/knut.file.dar ファイルを Media Server の ¥root ディレクトリにコピーします。
      scp knut.file.dar root@Mediaserver_IP_Address:/root

      複数の Media Server がある場合は、このファイルを各ノードにコピーします。

  3. Media Server に移動し、以下のようにマウントポイントと VIPA をオンラインにします。

    例えば、MediaServer1 の場合は以下のコマンドを使用します。

    		chrg -o online SUT_BASE_MS1
  4. マウントポイントと VIPA がオンラインになっていることを確認します。 以下のコマンドを使用します (出力例)。
    		lssam
    lssam の例
  5. Media Server のインストールを実行するノードにログインします。
  6. 以下のテンプレートを使用して、Media Server の responsefile.txt を準備します (このテンプレートは、/software/IBM/ の下にあります)。
    responsefile.txt.TEMPLATE.Media_Server_Node_Medium_Deployment
  7. 以下のコマンドを使用して、SAMP を手動モードに設定します。
    		samctrl -M T
  8. Sametime Unified Telephony インストーラを使用して、Media Server のみをインストールします。次のコマンドを使用します。
    		./install.sh ms
  9. 以下のコマンドを使用して、Media Server のマウントポイント上に ID ファイルを作成します。
    touch /enterprise/MS1
  10. SAMP の手動モードをオフにします。
    		samctrl -M -F
  11. 例えば、Media Server 2 の Media Server を開始します。
    		chrg -o online NODE_MGR_MS2
  12. 以下のコマンドを使用して、Media Server が稼働していることを確認します (出力例)。
    		lssam
    lssam の例
  13. テレフォニーアプリケーションサーバーコンポーネントの自動開始を防止するために、以下のコマンドを起動します。
    		chkconfig symphoniad off
    		chkconfig solidSYM off
    		chkconfig websphere off
スタンバイノードの準備

テレフォニーアプリケーションサーバーと Media Server を IBM Sametime Unified Telephony デプロイメントに 正常にインストールしたら、いくつかの追加ファイル (/etc/init.d/ 内にある開始スクリプトなど) を スタンバイノードにコピーする必要があります。 この目的のために、専用のスクリプト (coldStandby.sh) が用意されています。

手順
  1. スタンバイノードを準備します。
    1. 以下のコマンドを使用して、TAS rs-scripts および構成ファイルを保存します。
      /enterprise/servicetools/install/bin/coldStandby.sh -s
    2. 以下のコマンドを使用して、テレフォニーアプリケーションサーバーを停止します。
      chrg -o offline CLUSTER_TAS1
    3. 以下のコマンドを使用して、クラスタをスタンバイノードに切り替えます。
      rgreq -o move -n node1 SUT_BASE_TAS1
      ここで node1 は、テレフォニーアプリケーションサーバーが稼働しているノードです。
    4. 切り替えが成功したかどうかを確認します。
      lssam
    5. スタンバイノードにログオンして、切り替えを確認します。 /enterprise を調べて、ID ファイルが存在することを確認します。 また、TAS1 が存在することも確認します。
  2. TAS rc-scripts と構成ファイルを復元します。
    /enterprise/servicetools/install/bin/coldStandby.sh –r 
    /enterprise/var/coldStandby
  3. 2 次ノード上に log ディレクトリがまだ存在しない場合は、以下のコマンドを使用して log ディレクトリを作成します。
    		mkdir /log
    		chmod 777 /log
  4. FAILED Offline 状態のリソースをリセットします。
    resetrsrc -s 'Name like "%"' IBM.Application 
    注: SAMP リソースが FAILED Offline 状態に達したときは、 SAMP リソースを手動でリセットする必要があります。
  5. システムコンポーネントの自動開始を防止します。
    		chkconfig symphoniad off
    		chkconfig solidSYM off
    		chkconfig websphere off
  6. シンボリックリンクが存在するかどうかを確認します。
    ls -al /usr/lib/liblog4cxx.so
    シンボリックリンクが存在する場合、応答はリンクが指すロケーションを示します。リンクが存在しない場合、以下のようにリンクを作成します。
    ln -s -T /enterprise/mediaserver/application_host/bin/liblog4cxx.so 
    /usr/lib/liblog4cxx.so
  7. スタンバイノード上でノードをオンラインに設定します。
    chrg -o online CLUSTER_TAS1 
  8. すべてのコンポーネントが期待どおりに稼働していることを確認します。
    lssam
  9. FAILED Offline 状態のリソースをリセットします。
    resetrsrc -s 'Name like "%"' IBM.Application
  10. 1 次ノードにフェイルバックします。
    rgreq -o move -n <standby_node> SUT_BASE_TAS1
    ここで standby_node は、スタンバイノードのホスト名です。
テレフォニー制御サーバーの構成の更新

テレフォニーアプリケーションサーバーの仮想 IP アドレスをテレフォニー制御サーバーのパケットフィルタルールに追加する必要があります。

手順
  1. テレフォニー制御サーバーのコマンドラインインターフェースを (エキスパートモードではなく) 標準モードで開始します。
    startCli
  2. 以下のオプションを、この順に選択します。
    1. 6
    2. 8
    3. 4
    4. 作成
  3. テレフォニーアプリケーションサーバー IP に関する以下のすべてのルールを追加します。CMP を使用してテレフォニー制御サーバーにアクセスする各テレフォニーアプリケーションサーバーに対して、この変更を行います。
    ---------------------------------------------------------------
    Packet Filter Rule Name: TAS1_PHY
    Description: SNMP Packets from TAS1 to Node IP
    Remote FQDN:
    Remote IP Address: <Virtual IP Address of TAS1>
    Remote NetMask: 255.255.255.255
    Remote Port Begin: 0
    Remote Port End: 0
    Direction: InComing
    Local Host : bond_node_alias
    Local Port Begin: 161
    Local Port End: 0
    Transport Protocol: UDP
    Action : Allow
    ---------------------------------------------------------------
    Packet Filter Rule Name: TAS1_PHY_FTPC
    Description: FTP Control from Trusted TAS1 to Node IP
    Remote FQDN:
    Remote IP Address: <Virtual IP Address of TAS1>
    Remote NetMask: 255.255.255.255
    Remote Port Begin: 0
    Remote Port End: 0
    Direction: InComing
    Local Host : bond_node_alias
    Local Port Begin: 21
    Local Port End: 0
    Transport Protocol: TCP
    Action : Allow
    ---------------------------------------------------------------
    Packet Filter Rule Name: TAS1_PHY_FTPD
    Description: FTP Data from TAS1 to Node IP
    Remote FQDN:
    Remote IP Address: <Virtual IP Address of TAS1>
    Remote NetMask: 255.255.255.255
    Remote Port Begin: 0
    Remote Port End: 0
    Direction: InComing
    Local Host : bond_node_alias
    Local Port Begin: 20
    Local Port End: 0
    Transport Protocol: TCP
    Action : Allow
    ---------------------------------------------------------------
    Packet Filter Rule Name: TAS1_SOAP_Node
    Description: SOAP from TAS1 to Node IP
    Remote FQDN:
    Remote IP Address: <Virtual IP Address of TAS1>
    Remote NetMask: 255.255.255.255
    Remote Port Begin: 0
    Remote Port End: 0
    Direction: InComing
    Local Host : bond_node_alias
    Local Port Begin: 8767
    Local Port End: 0
    Transport Protocol: TCP
    Action : Allow
    ---------------------------------------------------------------
    Packet Filter Rule Name: TAS1_SOAP_Node2
    Description: SOAP from TAS1 to Node2 IP
    Remote FQDN:
    Remote IP Address: <Virtual IP Address of TAS1>
    Remote NetMask: 255.255.255.255
    Remote Port Begin: 0
    Remote Port End: 0
    Direction: InComing
    Local Host : bond_partner_alias
    Local Port Begin: 8767
    Local Port End: 0
    Transport Protocol: TCP
    Action : Allow
    ---------------------------------------------------------------
    Packet Filter Rule Name: TAS1_BCOM_SOAP_Node
    Description: BCOM SOAP from TAS1 to Node IP
    Remote FQDN:
    Remote IP Address: <Virtual IP Address of TAS1>
    Remote NetMask: 255.255.255.255
    Remote Port Begin: 0
    Remote Port End: 0
    Direction: InComing
    Local Host : bond_node_alias
    Local Port Begin: 8768
    Local Port End: 0
    Transport Protocol: TCP
    Action : Allow
    ---------------------------------------------------------------
    Packet Filter Rule Name: TAS1_BCOM_SOAP_Node2
    Description: BCOM SOAP from TAS1 to Node2 IP
    Remote FQDN:
    Remote IP Address: <Virtual IP Address of TAS1>
    Remote NetMask: 255.255.255.255
    Remote Port Begin: 0
    Remote Port End: 0
    Direction: InComing
    Local Host : bond_partner_alias
    Local Port Begin: 8768
    Local Port End: 0
    Transport Protocol: TCP
    Action : Allow
    ---------------------------------------------------------------
    Packet Filter Rule Name: TAS1_VIP
    Description: SNMP Packets from TAS1 to OAM Virtual IP
    Remote FQDN:
    Remote IP Address: <Virtual IP Address of TAS1>
    Remote NetMask: 255.255.255.255
    Remote Port Begin: 0
    Remote Port End: 0
    Direction: InComing
    Local Host : oam_ip_alias
    Local Port Begin: 161
    Local Port End: 0
    Transport Protocol: UDP
    Action : Allow
    ---------------------------------------------------------------
    Total Number of Packet Filter Rules Retrieved : 10
    Packet Filter Rule Name: TAS1_FTPC
    Description: FTP Control from Trusted TAS1 to OAM Virtual IP
    Remote FQDN:
    Remote IP Address: <Virtual IP Address of TAS1>
    Remote NetMask: 255.255.255.255
    Remote Port Begin: 0
    Remote Port End: 0
    Direction: InComing
    Local Host : oam_ip_alias
    Local Port Begin: 21
    Local Port End: 0
    Transport Protocol: TCP
    Action : Allow
    ---------------------------------------------------------------
    Packet Filter Rule Name: TAS1_FTPD
    Description: FTP Data from TAS1 to OAM Virtual IP
    Remote FQDN:
    Remote IP Address: <Virtual IP Address of TAS1>
    Remote NetMask: 255.255.255.255
    Remote Port Begin: 0
    Remote Port End: 0
    Direction: InComing
    Local Host : oam_ip_alias
    Local Port Begin: 20
    Local Port End: 0
    Transport Protocol: TCP
    Action : Allow
    ---------------------------------------------------------------
    Packet Filter Rule Name: TAS1_DB
    Description: Solid DB Access from TAS1 to OAM Virtual IP
    Remote FQDN:
    Remote IP Address: <Virtual IP Address of TAS1>
    Remote NetMask: 255.255.255.255
    Remote Port Begin: 0
    Remote Port End: 0
    Direction: InComing
    Local Host : oam_ip_alias
    Local Port Begin: 16760
    Local Port End: 0
    Transport Protocol: TCP
    Action : Allow
    ---------------------------------------------------------------
    Packet Filter Rule Name: TAS1_SFTP
    Description: SFTP from TAS1 to OAM Virtual IP
    Remote FQDN:
    Remote IP Address: <Virtual IP Address of TAS1>
    Remote NetMask: 255.255.255.255
    Remote Port Begin: 0
    Remote Port End: 0
    Direction: InComing
    Local Host : oam_ip_alias
    Local Port Begin: 22
    Local Port End: 0
    Transport Protocol: TCP
    Action : Allow
    ---------------------------------------------------------------
    Packet Filter Rule Name: TAS1_SOAP
    Description: SOAP from TAS1 to OAM Virtual IP
    Remote FQDN:
    Remote IP Address: <Virtual IP Address of TAS1>
    Remote NetMask: 255.255.255.255
    Remote Port Begin: 0
    Remote Port End: 0
    Direction: InComing
    Local Host : oam_ip_alias
    Local Port Begin: 8767
    Local Port End: 0
    Transport Protocol: TCP
    Action : Allow
    ---------------------------------------------------------------
    Total Number of Packet Filter Rules Retrieved : 1
    Packet Filter Rule Name: SnmpOffBoardAssistant2_<Virtual IP Address of TAS1>
    Description: SNMP Packets from Assistant Server to bond partner IP
    Remote FQDN:
    Remote IP Address: <Virtual IP Address of TAS1>
    Remote NetMask: 255.255.255.255
    Remote Port Begin: 0
    Remote Port End: 0
    Direction: InComing
    Local Host : bond_partner_alias
    Local Port Begin: 161
    Local Port End: 0
    Transport Protocol: UDP
    Action : Allow
    ---------------------------------------------------------------
フェイルオーバーインストール済み環境のテスト

このトピックでは、1 次テレフォニーアプリケーションサーバーノードとスタンバイテレフォニーアプリケーションサーバーノードで 実行できるフェイルオーバーテストをいくつか説明します。

このタスクについて
フェイルオーバーインストール済み環境が機能していることを確認するために実行するテストがいくつかあります。 以下のテストは、これらのコンポーネントに関する一般的なガイドラインです。
手順
  1. アクティブノードをリブートします。 切り替えが成功すること、および切り替えに要する時間が手動による切り替えと同等であることが必要です。
  2. アクティブノードの電源をオフにします。 切り替えが成功するかどうかを確認します。
  3. 外部のネットワークにつながるネットワークケーブルを取り外します。 切り替えが成功するかどうかを確認します。
  4. マウントがビジーである間 (例えば、シェルを開いて、マウントされたディレクトリに切り替えることによりマウントがビジーである間) に、 スタンバイノードに切り替えます。 期待される結果は、切り替えが成功すること、およびシェルが閉じていることです。
  5. 以下のコマンドを使用して、プロセスを手動で停止します。
    symphoniad stop 
    期待される結果は、切り替えが行われずに、同じノード上でプロセスが迅速に再起動されることです。
  6. 切り替えを手動でテストします。切り替えを行うには、以下のコマンドを呼び出します。
    		rgreq -o move -n <node> BASE_TAS1 		
    ここで node は、現在アクティブなノードです。 現在アクティブなノードを確認するには、lssam コマンドを使用します。
次のタスク

すべてのテレフォニーアプリケーションサーバーがデプロイされていて、フェイルオーバーシステムが作動していることを確認したら、SIP Proxy and Registrar をインストールします。

テレフォニーアプリケーションサーバーコンポーネントの更新またはアンインストール

(テレフォニーアプリケーションサーバー、IBM WebSphere Application Server、Media Server など) どのコンポーネントでも、 更新またはアンインストールすることが可能です。

このタスクについて

テレフォニーアプリケーションサーバー、WebSphere Application Server、Media Server をアンインストールまたは更新することにより、コンポーネントを管理します。 以下のステップは、これらのコンポーネントに関する一般的なガイドラインです。

手順
  1. 更新するリソースを、最初のインストールを実行したノードに切り替えます。 rpm データベースは、1 次ノード上で整合性があります。rgreq コマンドを使用してください。
  2. クラスタを手動モードに設定します。
    		samctrl -M T
  3. インストールの指示に従って、更新またはアンインストールを実行します。例えば、 OSGI コンテナのアンインストールと再インストールを行うには、以下のようにします。
    ./uninstall.sh osgi
    ./install.sh osgi
  4. 更新するには、クラスタを自動モードに設定します。
    samctrl -M F

SIP Proxy and Registrar サーバーのインストール

IBM Sametime デプロイメントに SIP Proxy and Registrar が含まれていない場合は、Sametime Unified Telephony で使用するためにここでインストールします。SIP Proxy and Registrar が既にデプロイされている場合は、このタスクを省略します。

このタスクについて

Sametime Unified Telephony は、Sametime デプロイメントによって提供される SIP Proxy and Registrar を使用します。各テレフォニーアプリケーションサーバーが専用の SIP Proxy and Registrar と共にインストールされていた以前のリリースとは異なり、Sametime Unified Telephony デプロイメント全体が、SIP Proxy and Registrar を基本 Sametime デプロイメントと共有します。

Sametime Unified Telephony をインストールする前に、Sametime のデプロイが正常に完了している必要があります。Sametime デプロイメントに SIP Proxy and Registrar が含まれていない場合は、ここでインストールできます。 SIP Proxy and Registrar サーバーまたはクラスタの 1 つのインスタンスが、Sametime Unified Telephony デプロイメント全体に対応できます。

SIP Proxy and Registrar のインストールは、Sametime Media Manager パッケージを使用して行います。SIP Proxy and Registrar を Sametime Unified Telephony 専用にインストールする場合は、インストール時に SIP Proxy and Registrar コンポーネントのみを選択します。SIP Proxy and Registrar のインストール手順については、Sametime Wiki にある資料『Administering Sametime』のセクション「Installing a Sametime Media Manager on Linux or Windows」を参照してください。

サービスの開始と停止

IBM Sametime Unified Telephony には、テレフォニーアプリケーションサーバーとテレフォニー制御サーバー上のサービスを開始および停止するためのコマンドセットが用意されています。

テレフォニー制御サーバーは、3 つの異なるレベルで作動でき、ランタイムはデータベースから別個に制御されます。テレフォニーアプリケーションサーバーでは、IBM WebSphere Application Server とフレームワークを別個に制御できます。詳細は、次のトピックを参照してください。

テレフォニーアプリケーションサーバーの開始と停止

IBM Sametime Unified Telephony デプロイメントで、テレフォニーアプリケーションサーバー上の IBM WebSphere Application Server およびフレームワークを開始および停止するには、以下のコマンドを発行します。

手順
  1. 以下のコマンドを実行して SAMP を手動モードにし、開始、停止、状況のコマンドの実行を妨げないようにします。
    samctrl -M T
  2. 以下の手順で、WebSphere Application Server を開始または停止します。
    1. テレフォニーアプリケーションサーバーで Putty を使用してターミナルを開きます。
    2. root としてログインします。
    3. 以下のいずれかのコマンドを実行します。
      • 開始: # /opt/IBM/WebSphere/AppServer/bin/startServer.sh server1
      • 停止: # /opt/IBM/WebSphere/AppServer/bin/stopServer.sh server1 -user WAS_Admin_Username -password WAS_Admin_Password
      • 状況確認: # /opt/IBM/WebSphere/AppServer/bin/serverStatus.sh server1 -user WAS_Admin_Username -password WAS_Admin_Password
  3. 以下の手順でフレームワークを開始または停止します。
    1. テレフォニーアプリケーションサーバーで Putty を使用してターミナルを開きます。
    2. root としてログインします。
    3. 以下のいずれかのコマンドを実行します。
      • 開始: # /etc/init.d/symphonia start
      • 停止: # /etc/init.d/symphonia stop
      • 状況確認: # /etc/init.d/symphonia status
  4. solidDB® を開始または停止します。
    1. テレフォニーアプリケーションサーバーで Putty を使用してターミナルを開きます。
    2. root としてログインします。
    3. 以下のいずれかのコマンドを実行します。
      • 開始: # /etc/init.d/solidSYM start
      • 停止: # /etc/init.d/solidSYM stop
      • 状況確認: # /etc/init.d/solidSYM status
テレフォニー制御サーバーの実行レベル

テレフォニー制御サーバーの実行レベルを変更するには、以下のステップを実行します。

このタスクについて
テレフォニー制御サーバーノードは、以下に示す 3 種類のレベルのいずれかで作動できます。
  • レベル 4: テレフォニー制御サーバーとソリッドデータベースの両方が稼働している状態。
  • レベル 3: テレフォニー制御サーバーはダウンしているが、ソリッドデータベースは稼働している状態。
  • レベル 2: テレフォニー制御サーバーとソリッドデータベースの両方がダウンしている状態。
手順
  1. 実行レベルを変更するには、最初に root ユーザーとしてテレフォニー制御サーバーノードにログインして srxctrl コマンドを実行し、次のディレクトリに切り替えます。 # cd /unisphere/srx3000/srx/startup
  2. 次に、srxctrl コマンドを実行します。テレフォニー制御サーバーノードの実行レベルを変更するコマンドは、2 つの引数を取ります。第 1 の引数は、コマンドが実行されているローカルノードの実行レベルで、第 2 の引数は、リモートテレフォニー制御サーバーノードの実行レベルです。テレフォニー制御サーバーの実行レベルを変更するコマンドは、次のとおりです。 # ./srxctrl 4 4
  3. コンソールを終了する前に、サーバーの状況をチェックします。次のコマンドを実行します。 # ./srxqry
サービスを中断しないで (両方の) テレフォニー制御サーバーノードを再起動するには、最初に # ./srxctrl 3 4 を発行して、1 次ノードを停止します。1 次ノードを開始し、2 次ノードを停止するには、# ./srxctrl 4 3 を発行します。2 次ノードを開始し、2 つのノードを実行レベル 4 に再び設定するには、# ./srxctrl 4 4 を発行します。出力の例を以下に示します。
 -- --- srxqry started on Tue Feb  2 09:05:02 GMT 2010 ---  
-- OS          : Linux
-- Platform    : x3650T 
-- Cluster     : DUBTCS02
                     Node name             Status
                    ---------             ------   
Local  Node  :   dubtcs02node1         Online at state 4   
Remote Node  :   dubtcs02node2         Online at state 4   
- Get running applicationsinformation on dubtcs02node1, please stand by...
- Checking for running applicationson dubtcs02node1... -- UCE and all 
signaling managers are up and running on dubtcs02node1  Found the 
following interfaces configured from RTP configuration! 
For Node: dubtcs02node1  
CCM 0.5      Vip:             192.168.100.192
Up 
CCM 1.0      Vip:             192.168.100.133
Up 
CCM TGCP     Vip:             192.168.100.199
Up 
CSTA         Vip:             192.168.100.246
Up 
SIP          Vip:             192.168.100.236
Up 
SIP TLS Auth Vip:             192.168.100.239
Up  

- Checking for running applicationson dubtcs02node2... 
-- UCE and all signaling managers are up and running on 
dubtcs02node2  Found the following interfaces configured 
from RTP configuration! 
For Node: dubtcs02node2  
CCM 0.5      Vip:             192.168.100.194
Up 
CCM 1.0      Vip:             192.168.100.159
Up 
CCM TGCP     Vip:             192.168.100.201
Up 
SIP          Vip:             192.168.100.238
Up 
SIP TLS Auth Vip:             192.168.100.245
Up  -- -
-- srxqry ended on Tue Feb  2 09:05:11 GMT 2010 ---

Sametime Unified Telephony をユーザーにデプロイする

Sametime クライアントと共にインストールされる IBM Sametime Unified Telephony 機能を有効にします。

手順
  1. Sametime Connect クライアントで Sametime Telephony 機能を有効にします。

    リリース 8.5.1 以降、テレフォニー機能が Sametime クライアントに自動的にインストールされるようになりました。Sametime Standard インフォメーションセンターのトピックである「Sametime Telephony を使用可能にする」で説明しているように、テレフォニー機能は、Sametime のユーザーインターフェースから有効にします。

  2. デプロイメント環境での各 Sametime Community Server で、sametime.ini ファイルを編集し、IGNORE_SUBSCRIBES_ABOVE_MAX 設定の制限値を指定します。

    詳細は、Sametime Standard インフォメーションセンターのトピックである「連絡先リストのサイズを制御するための詳細設定」を参照してください。

インストールの検証

IBM Sametime Unified Telephony デプロイメントの構成をテストします。

始める前に
テレフォニー制御サーバーとテレフォニーアプリケーションサーバーの初期構成を実行しておく必要があります。また何人かのユーザーをプロパティービジョンしてコールが正しく動作するかをテストする必要があります。
このタスクについて
このテストフェーズでは、テレフォニーアプリケーションサーバーとテレフォニー制御サーバーの正常性をチェックします。実際のテレフォニー制御サーバーソフトウェアのバージョンを出力できます。接続および正常性状況をテストした後で、この構成をお客様の環境と統合できます。
手順
  1. 以下のテストでは、テレフォニーアプリケーションサーバーがテレフォニー制御サーバーおよび Sametime Community Server と共に作動できることを検証します。
    1. SSH を通じて root としてログインします。
    2. 次の手順で、ポート 1516 で Sametime サーバーへの 2 つの接続がアクティブかどうかをテストします。
      netstat -an |grep 1516
    3. ポート 1040 でテレフォニー制御サーバーの CSTA への 1 つの接続がアクティブかどうかをテストします。
      netstat -an |grep 1040
      注: ポート 1040 の接続は、CSTA 接続が Common Management Portal (CMP) 内で構成されてコールが実行されるまで、アクティブになりません。
    4. ポート 5060 で Sametime SIP Proxy and Registrar への 1 つの接続がアクティブかどうかをテストします。
      netstat -an |grep 5060
    5. セキュアポートで Sametime SIP Proxy and Registrar への 1 つのセキュア (TLS) 接続がアクティブかどうかをテストします。
      netstat -an |grep secure_port.

      SIP Proxy and Registrar が使用するセキュア SIP ポートの判別の手順を実行することにより、セキュア SIP ポートを判別することができます。

    6. ポート 5070 で SIP Conference への 1 つの接続がアクティブかどうかをテストします。
      netstat -an |grep 5070
    7. ポート 5071 で SIP TLS Conference への 1 つの接続がアクティブかどうかをテストします。
      netstat -an |grep 5071
  2. 以下の手順で、テレフォニー制御サーバーのインストールを確認します。
    1. テレフォニー制御サーバーに root としてログインします。
    2. 以下のコマンドを実行して、テレフォニー制御サーバーの正常性チェックを行います。
      /unisphere/srx3000/srx/startup/srxqry -v
    3. テレフォニー制御サーバーでパッチセット照会を実行して、すべてのパッチが適用されたことを確認します。
      /unisphere/srx3000/srx/version/pkgversion -ps
  3. 以下に示す各テストでフェイルオーバーが機能していることを確認します。
    1. アクティブノードをシャットダウンします。
      • Issam コマンドを実行し、すべてのプロセスがスタンバイノードで実行されていることを確認します。
      • 仮想 IP アドレス (VIP) を使用して WebSphere と CMP にログインできることを確認します。
      • 1 対 1 のコールと電話会議を行います。
    2. アクティブノードを再起動します。
      • Issam コマンドを実行し、すべてのプロセスがスタンバイノードで実行されていることを確認します。
      • 仮想 IP アドレス (VIP) を使用して WebSphere と CMP にログインできることを確認します。
      • 1 対 1 のコールと電話会議を行います。
    3. 以下のコマンドを実行します。rgreq -o move -n ....
      • Issam コマンドを実行し、すべてのプロセスがスタンバイノードで実行されていることを確認します。
      • 仮想 IP アドレス (VIP) を使用して WebSphere と CMP にログインできることを確認します。
      • 1 対 1 のコールと電話会議を行います。
    4. WebSphere Application Server を停止します。
      • Issam コマンドを実行し、すべてのプロセスがスタンバイノードで実行されていることを確認します。
      • 仮想 IP アドレス (VIP) を使用して WebSphere と CMP にログインできることを確認します。
      • 1 対 1 のコールと電話会議を行います。
    5. フレームワークをシャットダウンします。
      • Issam コマンドを実行し、すべてのプロセスがスタンバイノードで実行されていることを確認します。
      • 仮想 IP アドレス (VIP) を使用して WebSphere と CMP にログインできることを確認します。
      • 1 対 1 のコールと電話会議を行います。
  4. /log/install/IBM* 内のファイルでインストールのフットプリントを調べることにより、Media Server が正しくインストールされたことを確認し、このファイルのどこにも「ERROR」が記録されていないことを確認します。
次のタスク

この時点で、Sametime Unified Telephony サーバーはすべて稼動しているはずですが、ユーザーにデプロイする前に、いくつかの構成タスクを完了する必要があります。デプロイメントの構成に関するセクションに進みます。